[PD] "G05.execution.order" issue (bug? just wrong?)

[IOhannes m zmölnig]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150907/6c39e7b6/attachment-0001.sig>