[PD-dev] tcl errors in the PD console... (using dynamic patching from tot directory listing)

B. Bogart ben at ekran.org
Tue Mar 22 21:09:56 CET 2005


Hey all,

I've posted to the list before about getting tcl errors in some of my
new patches. Well after more digging I have finally found the cause.

I'll first explain the patch a bit. tcl_errors.pd is the toplevel patch.
It contains a number of dir2abstractionArray abstractions. These are
abstractions that create dynamic subpatches of abstractions. The
abstractions are read from a directory you specify via set-dir messages.
A TOT object reads the directory and then spits out a list of all the
abstractions. Each one is then dripped and has the extension removed.
This is sent to the dynamic patch generator that actually creates the
"array" of abstractions in a subpatch. The dir2abstractionArray
abstraction brokers the communication from the outside to the various
abstractions contained in the array. The first two inlets and outlets
get routed to the "selected" abstraction. The selected abstraction is
chosen by index value.

I'm using this abstraction so that an end-user can drop custom
abstractions into special directories and they automatically get updated
in the GUI when the patch is loaded. This could even happen while PD is
running by sending an update message.

Due to the complexity of the GOP that uses this abstraction I had a lot
of trouble seeing where the tcl errors were coming from.

When we have only one dir2abstractionArray in a patch then it behaves
very well (on OSX) on linux if you try and update the array too fast you
get tcl errors. On both linux and OSX if we have more than one instance
of this abstraction then all hell breaks loose and we get constant tcl
errors. :(

The most obvious solution is to send the update (pattern) messages in
sequence and not all at once. The problem is that the solution needs to
work in every pixelTANGO patch, no matter how many abstractions there
are or what order they are in. There is no way of picking out a
particular abstraction to go first. How do the others know when its
done? I had been using delays, but since all the abstractions are the
same, they all get delayed for the same amount of time. I guess I could
divide some constant by the $0 variable to get a unique delay for each
abstraction. Does that make sense??

I'm not sure if this would be considered a real bug, since its so
bleeding edge and perhaps is not supposed to work at all..

Krzysztof, are the tcl errors happening because I'm running simultaneous
"query" commands that are being bogged down by the dynamic patching?

I'm doing a workshop on thursday night and I would really like to get
this fixed, I feel like I'm very close since I can actually make a
test-patch. I don't have any brilliant ideas about how to fix it though.

Using the test patch:

1. Make sure tot and zexy are working
2. save all the patches in one directory and then open the tcl_errors.pd
    file.
3. Change the set-dir arguments to a directory on your machine that is
    in your PD path. (better NOT choose the directory containing the
    tcl_errors patch) or try the sending "sel-dir" message.
4. Try the "pattern *.pd" message at the top and look for tcl errors.
    If you click it slowly enough you should get no tcl errors.
5. Try the "pattern *.pd" message attached to multiple abstractions.
    This will cause tcl errors every time.

A patch fix would be good for now, but it would be nice if these errors
could somehow be avoided in the future (perhaps with changes in pd and
or TOT?)

Thank you all for your time.
I took me months to get this far, I hope there are some brilliant ideas
to fix things out there.

B. Bogart
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dir2abstractionArray.pd
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050322/569022df/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dirlist.pd
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050322/569022df/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dirpanel.pd
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050322/569022df/attachment-0001.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stripExtension.pd
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050322/569022df/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tcl_errors.pd
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050322/569022df/attachment-0002.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050322/569022df/attachment.pgp>


More information about the Pd-dev mailing list