> 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. _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
