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

[Miller Puckette]

Well, it's not safe either to set the name of a canvas, nor would it
work to set its search path, after it has been instantiated.  Even
'loadbang time' is too late... so the mechanism has to be somehow outside
the regular functionality of a patch.  The old 'declare' object did this,
by inserting in the saved patch some 'declarations' which afected the
environment in which the patch was loaded.  A patch that contained a
"declare path=lib" object would actually save as:

#N canvas 282 166 521 402 10;
#X declare path=lib;
#X obj 10 10 abstraction-in-the-library ...;
#X obj 20 20 declare path=lib;
...

in other words, the declare object is created in teh usual "obj" way (line 4)
but would magically insert a _message_ "declare" to go to the canvas before
creating anything (line 2).

It's not ideal because changing the "declare" object would not take effect
until the next time the patch was loaded.  Perhaps changing a "declare" should
automatically provoke a reload in th esame way that saving an abstraction
does...

cheers
Miller

On Sun, Jan 15, 2006 at 06:09:05PM +0100, IOhannes m zmoelnig wrote:
> Hans-Christoph Steiner wrote:
> 
> >
> >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  
> 
> that's what i was trying to explain, though i was calling it [canvas] 
> instead of [meta].
> 
> >[meta] object, then make [namecanvas], [declare], [import]/[using] as  
> >abstractions based on [meta].
> >
> 
> hmm, well; i don't see clearly how this should work. the [meta] in an 
> abstraction [namecanvas] would refer to [namecanvas]'s meta-data, while 
> you intend it to refer to the parent's meta-data.
> so we would need something like a macro! - no we better not...
> 
> mfg..fwer
> IOhannes
> 
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev