On 09/07/2015 07:16 PM, Alexandre Torres Porres wrote:
it's undefined.
But how is it "undefined behaviour"? For trigger, for example, I understand the order of connections will define the order of messages being sent, right? I mean, every time I've tested it, it worked. But is it at some level really "undefined" and might not work?
well "might not work" is probably the wrong wording here: i think it's more "might not do what you expect".
many uses of signal processing in the Pd world do not require block synchronicity (e.g. when you build a synth, you mostly won't notice if an envelope triggers 64 samples late). that's why you often get away with the undefined behaviour in signal domain.
and what would the internal workings be for this audio connections? It's still unclear to me
the order of execution for signal objects is (with "execute" i mean "calling the DSP perform routine"):
- all inputs of an object must be filled before it can be executed.
this means:
- whichever object A has an outlet~ that is connected to the inlet~ of
an object B, will be executed before B.
- if the above does not resolve into a unique order of execution, then
the object that was created first will be executed first.
#1 is the reason, why order-forcing works #2 is what we call "undefined" (as you cannot see this from staring at the patch). the reason why the creation order becomes amajor factor is that this maps well to the internal data representation when resolving execution order (objects are added to a linked-list; if some objects have the same priority, the new object will be added at the end (of that priority)).
i hope this explains it.
fmdsf IOhannes