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