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
[email protected]
http://www.matteosistisette.com
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
