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.