[Pd] Feature Request: trigger editing

[Mathieu Bouchard]

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