On Jan 15, 2006, at 4:18 AM, IOhannes m zmoelnig wrote:
Miller Puckette wrote:
This might be a good thing to add to the properties menu, but some mechanism is also needed to do it programmatically. For example, an abstraction might want to name itself and then send messages to inform other part of the patch of the name. Perhaps this should be part of a larger "declaration" mechanism that would also allow patches to specify search paths and other startup needs. ISPW Max had a "declare" object so you could write "declare path=lib:../lib" to add to the search path. Somthing like that is also needed in Pd.
hmm, but using an object ([declare]) has the same problems as using another object ([namecanvas]).
probably it would be better to really store data (canvasname, paths,...,settings) in the "properties" of the canvas, AND make an object to talk to this properties. this could be an object [canvas] it would have one inlet to send messages like [vis 1( or [name $0-canvas( to ourselves (the canvas we are in). it would have one outlet, so we can get all messages sent to the canvas (no matter what its name may be)
the good thing would be, that the object would not hold the data by itself (nor give the user the illusion to do so). so if the canvas would be renamed to "idontplayguitar" (via a message to [canvas]) and then you would delete the [canvas] object, the canvas would still be called "idontplayguitar" (just like when you are deleting a [send] object, you do not undo all messages already sent through it).
btw, i even think it better to have an inlet (like the one in [canvas] to talk to a canvas than a send-name. this would (hopefully) demystify much of the magic that is currently done with "dynamic" patching (i put the "dynamic" in quotes, since i am talking more about "vis 1" than "clear").
So it seems between canvas names and namespace declarations/lib path need to be some kind of patch meta data which is able to be controlled from patch space and the properties panel.
Perhaps this meta data can be stored in as part of the patch itself and stored in the .pd file with the addition of a #N meta line. Then this data could be viewed and edited from the patch's properties panel, and objects like [namecanvas], [declare], [import]/[using] would be able to manipulate this data as well.
In this situation, the meta data object would have an inlet to set the data, and an outlet to fetch the data. This could be done with a [meta] object, then make [namecanvas], [declare], [import]/[using] as abstractions based on [meta].
.hc
________________________________________________________________________ ____