[PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

Matteo Sisti Sette matteosistisette at gmail.com
Sun Apr 18 12:06:57 CEST 2010

Hi frank,

Thank you for the clarifications.

However, I don't see how you would "sort" (i.e. force a desired 
execution order) [send~]s and [receive~]s in a useful way, that is in 
situations where you need them.

If the only way to force execution order is by actually creating a 
"wired" path with subpatches, then it seems to me it is useless for 
[s~]s and [r~]s because if you can sort them in a wired way, then you 
can just replace them by wires, so you didn't need them in the first place.

Is there some other way of "sorting" them??

 > It's the
 > same for messages, that's why I always keep telling newbies to
 > use more
 > [trigger] objects.

No it's not the same. There is a big difference. A [s] and a [r] (no 
tilde) _is_ equivalent to a wired connection. Ok if you have a [s xxx] 
and multiple [r xxx]s you cannot control the order of execution of the 
receives, but you _do_ know that all those [r]s (and their subtree) will 
be executed before the following "sibling" nodes of the [s] are 
executed. That is exactly the same that would happen if you had a wired 
connection between what is connected to [s] and all the subtrees that 
are connected to the [r]s: a direct one-to-many wired connection without 
a [trigger].

The problem with [s~] and [r~] is not the execution order among the 
multiple [r~]s, i.e. which [r~] is executed first. The problem is that 
you don't know whether the [s~] or the [r~] is executed first. That has 
no analogy with [s] and [r] as far as i can see.

Matteo Sisti Sette
matteosistisette at gmail.com

More information about the Pd-list mailing list