btw, would it be thinkable to add the possibility to run the pd~ subprocess asynchronously?

This would be definitely possible. I think you only need to set the pipe read end in the parent process to non-blocking. The parent process tries to read the subprocess output and sends a block of zeroes on failure. This means that if the subprocess is late, it won't block the parent process, it will just miss one or more blocks of audio input

This could be a nice feature!

Christof

btw, would it be thinkable to add the possibility to run the pd~ subprocess asynchronously?

Think of a subprocess running a large Gem patch, that would potentially produce large CPU spikes;

you don't really care if this subprocess sometimes gets late, while you absolutely need the calling process (aka audio) to be on time.

As for the interface, I guess asynchronous behavior could be automatically enabled when ninsig=0 and noutsig=0?

Antoine

Le ven. 25 sept. 2020 à 12:43, Christof Ressi <info@christofressi.com> a écrit :

The "delay" setting is in ms, but the "-fifo" argument is in blocks.
Note that the "delay" setting is only valid for the parent process. In
the subprocess, all audio settings from the menu are ignored because the
relevant settings are passed via the [pd~] object).

Christof

On 25.09.2020 04:56, Fede Camara Halac wrote:
> 
> Aha! Thanks for clarifying! One more question, while I'm at it. Is the "delay" setting in blocks like the -fifo argument?
>
> Thanks a lot!
>
> f
>
>
> _______________________________________________
> 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

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list