Frank Barknecht escribió:
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.
Exactly: that's the situation where I most use them.
*If* order matters to you (it may not always do) you can still use the subpatch approach with dummy inlet~/outlet~ objects.
That's the part I don't understand. I mean I can't figure out the trick. I can easily imagine (and actually tried) how to patch things to force the desired order, but then again, I see myself obliged to do the wired connections that the [s~]/[r~]s were meant to avoid.
May you please make an example of the technique? I would be so grateful.
And don't forget the other application of s~/r~ where you actually *want* to have a delay of one block: feedback algorithms.
Yeah but in that case I would rather use a [delread~]/[delwrite~] pair, ¿no?
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.
Wow that sounds very interesting. I hope you will publish the paper on the internet so we can have a look
Thanks again cheers m.