There should be no latency if you [throw~] into the chain and [catch~] out of the chain instead of using [inlet~] and [outlet~], and put the [throw~], [clone~], and [catch~] each in its own successively connected subpatch (like we do with [delwrite~] and [delread~].

On Mon, Oct 28, 2019 at 11:18 AM Alex Norman <x37v.alex@gmail.com> wrote:
Btw, I made some abstractions to achieve this some time ago: https://github.com/x37v/pd-cascade
As Alex Poress points out, it may (probably does) add latency per Cascade.. it's been a while since I've used it..

Alex

On October 28, 2019 1:58:33 AM PDT, Christof Ressi <christof.ressi@gmx.at> wrote:
yes, the instances are processed in order. currently, this is an implementation detail, but I maybe we can make it a requirement and document it. your use case is certainly interesting and I don't see a reason why [clone] should *not* process canvasses in order.
 
@Miller what are your thoughts on this?
 
Christof
 
Gesendet: Montag, 28. Oktober 2019 um 01:54 Uhr
Von: "Matt Barber" <brbrofsvl@gmail.com>
An: pd-list@mail.iem.at
Betreff: [PD] clone dsp precedence
Quick question about [clone] – does the dsp graph order of [clone] instances match the numbered order of those instances within a [clone] object? I'm hoping to use [send~]/[receive~] pairs to make clone run serially rather than in parallel but that depends on whether they're guaranteed to run in order.
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list