On Tue, 4 Jul 2006, padawan12 wrote:
Perhaps the obvious thing that nobody is saying is to change the persistance characteristics of the trigger instance. Have it make a copy of itself which gets used to construct the new one?
jMax had that feature: in addition to having a constructor and a destructor, a class could optionally define a "reconstructor" which would be called instead of deleting+recreating.
Wouldn't that be generally useful to be able to insert new parameters in any order for other objects? What are the dangers?
Even with a "reconstructor", the reconstructor can't know where text has been inserted except by comparing strings.
Doing what you want with [t] is best done using a specialized GUI for that object class. This is done by setting up a t_widgetbehavior, writing several pages of C code and recompiling. (to do this in DesireData, you don't need to recompile and you don't need to write C code)
Anyway it seems in Pd, perhaps because passing parmeters to subpatches and abstractions isn't formal,
What do you mean "not formal" ?
BTW subpatches don't take any creation arguments (just a name). Abstraction instances do.
and there's not a handy way to wrap the parameters of a block of code, that trigger gets abused.
I don't know what you mean here. Want to give an example?
It's hard to say where exactly the type handling of Pd could be improved without taking the lid off a huge can-o-worms, but I can feel its limitations.
I don't think that we are talking about types?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada