I was just thinking about this, I think that the object controlling the meta data is a bit weird. I think that it would make more sense to be able to query the classname itself to set and get the meta data. This would be analogous to how you communicate with pd itself. The instance meta data doesn't currently exist and it'd be hard to do, so I say we can deal with that when it comes up.
All of this meta data would also be viewable and editable in the Properties panel. The receiver and classpath should be changable without a patch reload, since [namecanvas] can already change the meta "receive" name and [import], [using], and the Path preferences panel can change the path without a reload.
In addition to the properties panel, the meta data could be set with a message:
[;pd-mypatch.pd set classpath cyclone maxlib oscx zexy( [;pd-mypatch.pd set receive myname(
And retrieved with a message:
[;pd-mypatch.pd get classpath( [;pd-mypatch.pd get receive(
This would require some way of receiving the data. It wouldn't be essential, but it might come in handy. I don't have a clear idea of how best to do this. Maybe it could also be another meta type, you set a meta "send" name, then you can receive the messages. There could be a default, like "pd-meta". Like this:
[;pd-mypatch.pd set send mypatch-( [;pd-mypatch.pd get send(
The meta data could be stored like declare, then it would exist outside of the object loading order. It could then be stored in the file like this:
#N canvas 12 42 234 235 1; #X meta classpath cyclone maxlib oscx zexy; #X meta receive myname; #X meta send my-patch-meta; #X obj osc~; etc....
.hc
On Jan 15, 2006, at 12:38 PM, Miller Puckette wrote:
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
________________________________________________________________________ ____
"Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism." - retired U.S. Army general, William Odom