[PD] Send and receive execution order was Re: Zen Garden, re-implementing the wheel in C++?

[Matt Barber]

> Hi,
>
> 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:

http://lists.puredata.info/pipermail/pd-list/2010-04/077392.html


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.

Matt

PS -- I think my example has one unnecessary dummy outlet~/inlet~
pair, but I was being paranoid.