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 working well). 

On Mon, Aug 17, 2020 at 10:53 AM Josh Moore <kh405.7h30ry@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@christofressi.com> wrote:

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.

Christof

On 17.08.2020 19:27, Alexandre Torres Porres wrote:


Em seg., 17 de ago. de 2020 às 13:20, Christof Ressi <info@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;
thanks
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list