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

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> 
> 
> Plus, [canvas] would be easily confused with controlling [cnv] data.

i am pretty sure, that whenever miller will implement something like 
this, it will be called neither [canvas] not [meta], though it might 
still have some logic...idle reasoning...

> 
>>> [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...
> 
> 
> To solve this, the classname and the instance ID could be optional  
> arguments to [meta].  Then [meta] could be used from any patch to  
> control the meta data for any patch.  The default behavior for [meta]  
> with no arguments would then be to control the current patch.

but only if we _knew_ classname (simple) and instanceID (hard) beforehand.

> 
> I am not entirely sure about instance ID.  That would only be needed if  
> there was instance-specific meta data, which currently there is not.
> 

well, for me instance ID is something like $0 currently is. (it doesn't 
matter whether my ID is uniq just within the class or across the whole 
session).
--and i guess $0 has proven to be useful and indispensable to 
access...-- oops, seems like i am mixing the access to meta-data 
(setting the canvas-receiver) with the meta-data itself (the canvas' 
receivename).
however, if you want to set the canvas receiver to (e.g.) "$0-subpatch" 
you either need proper escaping (in order to literally set 
"$0-subpatch") or you are in trouble (setting all receivers to 
"1009-subpatch" is rather coarse...)
(i have to) read frank's mail on this

mfg.gtre
IOhannes