Hallo, padawan12 hat gesagt: // padawan12 wrote:
I've never really seen it as anything but an event flag. A stack of [t b b b b ] so that, as I now understand, I can sequence the evaluation order of my code better. And yes for that exact purpose it rather sucks, because if you want to insert an earlier one you have to move everything. 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? Wouldn't that be generally useful to be able to insert new parameters in any order for other objects? What are the dangers?
The problem with in/outlet management happens with all objects that generate their outlets on demand. Besides trigger this also involves route, select, (un)pack etc.
In a perfect world one would always create these objects with exactly the needed arguments in advance, but then it is one of the strong aspects of Pd that it leads to a more experimenting, playful style of development where changing object arguments can happen quite often.
There also is a related issue: Currently it is not possible to change the in/outlet count through messages, AFAIK, which hits everyone developing with [pyext] a bit all the time. ;)
But well, personally I must say I don't get hit by this problem as often as some years ago anymore, so it seems there must be some automatic workarounds in effect in my Thinking In Pd already...
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__