[PD-dev] bind abstraction-canvas to full classname (namecanvas)

[Hans-Christoph Steiner]

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

________________________________________________________________________ 
____

                             http://at.or.at/hans/