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@iem.at http://lists.puredata.info/listinfo/pd-dev