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

[Hans-Christoph Steiner]

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 at 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