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