[PD] New "fast-forward" message
kh405.7h30ry at gmail.com
Mon Aug 17 19:58:55 CEST 2020
I wonder if having an embedded version of pdlib built to do that would work
as you'd separate that from the scheduler, it would basically just run it's
own scheduler but you wouldn't have to manage threads (and i think it took
Csound quite a long time for them to get realtime with multiple threads
On Mon, Aug 17, 2020 at 10:53 AM Josh Moore <kh405.7h30ry at gmail.com> wrote:
> Yeah I think that would be a limitation that's unavoidable, because you're
> running at system clock rates vs audio clock rates. You'd have to spawn a
> new thread.
> On Mon, Aug 17, 2020 at 10:40 AM Christof Ressi <info at christofressi.com>
>> Try attached patch. Note that this works fine with pure DSP objects, but
>> it gives unexpected results once you add clocks (e.g. [metro], [del], etc.).
>> Sending a "bang" to [switch~] only advances DSP computation for the given
>> canvas (and all its subcanvases), but it doesn't advance the message
>> scheduler (which is global).
>> With this method, you can basically amortized DSP computations over a
>> given period of time.
>> On 17.08.2020 19:27, Alexandre Torres Porres wrote:
>> Em seg., 17 de ago. de 2020 às 13:20, Christof Ressi <
>> info at christofressi.com> escreveu:
>>> If your audio computation is pure DSP (i.e. no messages), you can
>>> "render" it by repeatedly banging the [switch~] object at any rate you
>>> like. Global DSP still has to be on, but the canvas would be switched off.
>> hmm, please elaborate;
>> 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