[PD] clone dsp precedence
brbrofsvl at gmail.com
Mon Oct 28 18:19:56 CET 2019
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 at gmail.com> wrote:
> Btw, I made some abstractions to achieve this some time ago:
> As Alex Poress points out, it may (probably does) add latency per
> Cascade.. it's been a while since I've used it..
> On October 28, 2019 1:58:33 AM PDT, Christof Ressi <christof.ressi at gmx.at>
>> 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?
>> *Gesendet:* Montag, 28. Oktober 2019 um 01:54 Uhr
>> *Von:* "Matt Barber" <brbrofsvl at gmail.com>
>> *An:* pd-list at 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 at lists.iem.at
>> mailing list UNSUBSCRIBE and account-management ->
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list