Hi Matteo,
On Sun, Apr 18, 2010 at 12:06:57PM +0200, Matteo Sisti Sette wrote:
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.
As I wrote, for "simple" connections it's not useful, but as soon as you do "bigger" calculations where order matters, it's a technique you need to know. Also s~/r~ are often used where direct connections are inconvenient, for example if you want to pass the target name by argument or if you would have a large number of connections/outlets or so. *If* order matters to you (it may not always do) you can still use the subpatch approach with dummy inlet~/outlet~ objects.
And don't forget the other application of s~/r~ where you actually *want* to have a delay of one block: feedback algorithms.
For s~/r~ may be not so useful as for delays and tabsend~/tabreceive~,though. In my upcoming paper for the LAC2010 in Utrecht, I present a way to do "control-rate" computations with signal objects as an optimization technique. For example you can calculate the "flatness" of a table by dividing the arithmetic and the geometric mean of the table calculating everything in the signal domain. There you have three operations: two means and one division. You need to make sure that you do both means before the division. The means are sent to a table, and to make sure, they are written before the division I use order forcing with subpatches.
Is there some other way of "sorting" them??
Not that I know of.
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.
I was comparing sorting DSP execution via subpatches/connections to sorting messages via the [trigger] object. These are very similar (well, not the same, but they are the equivalents.) I didn't mean to compare s/r with s~/r~ here, which, as you correctly described, are different. But that's because message handling and signal handling are very different: signals are "always on" and execute parallel inside of a block and are executed in reverse connection order ("top" objects are executed first which is some kind of "depth-last") while messages are scheduled on demand, one-by-one and depth-first.
But if you need to sort, use connections with signals and trigger with messages. *When* you need to sort depends on what you want to do.
Ciao
Frank