[PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?
brbrofsvl at gmail.com
Sun Apr 18 16:50:39 CEST 2010
> On Sun, Apr 18, 2010 at 01:07:21PM +0200, Matteo Sisti Sette wrote:
>> Frank Barknecht escribi?:
>> > *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.
> Attached is a very stupid example, which should show what I mean: Here
> various abstractions are layed out in a way, that they execute in order.
> Only one connection is used for order forcing, but still many s~/r~ are
> active, all properly ordered.
> Real life examples may not be so easy to sort, of course.
Here's a relatively simple real-life example I posted a couple weeks ago:
In this example I had an algebra problem that was complex enough that
it would have been way too messy to draw wires for each term, so
instead I named the terms and sent them via send~/receive~. However,
because it was algebraic and not "just" an fx patch (where latency may
or may not have mattered as much), I had to force execution order.
It's really useful in cases where you have 10 send~s in one subpatch,
because you can force order with just one connection -- sometimes a
lot cleaner than 10 wires, especially when those wires would have gone
to several different places.
PS -- I think my example has one unnecessary dummy outlet~/inlet~
pair, but I was being paranoid.
More information about the Pd-list