On Fri, 4 Aug 2006, hans@eds.org wrote:
I am sitting here with a performance venue with pounding bass after running my Swirler installation, and I just had a thought: what if there was a generic "properties" hook just like the "help" hook?
for each class [foo], right-click Help opens [foo-help], so using that precedent, i'd say, right-click Help would open [foo-prop]. Because helps uses its own path (-helppath), props could use their own path (-proppath) but I also wouldn't mind if they used the main path (-path).
a props patch could be connected to an object in any of several ways:
* through patchcords, but although the messagesystem wouldn't mind, the canvas/editor would go crazy.
* through send-symbols/receive-symbols, but not all objects naturally have a slot for those things: this scheme would require each object to support both a send and a receive. The send and receive of IEMGUIs wouldn't work for this purpose because they don't necessarily distinguish the one object that you want to control!
* through pointer atoms, but Pd's pointer system is very limited. It only allows to point to either a canvas/scalar pair or an array/word pair, neither of which are appropriate. Making a t_gpointer point to a [comport] object, for example, is worse than making a pointer atom hold a gem_state* or GridOutlet*.
until now, the properties ("attributes") patches that I have made are connected like this:
,--. ,--. | [foo] | [foo-prop] | `--' | `----------'
that is,
#N canvas 0 0 450 300 10; #X obj 50 0 foo-prop; #X obj 0 0 foo; #X connect 0 0 1 0; #X connect 1 1 0 0;
for example, http://gridflow.ca/gallery/lti.KMeansSegmentation-help.pd.gif
(or else they are nested, e.g. [#camera] wraps [#in videodev])
However, right-click Properties need something that is more dynamic than that. How that should be?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada