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
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
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
For now pd~ is synchronous regardless of whether there are input/output audio signals or not. I've been thinking about making an async possibility, but for now the only way to do that is launch two processes (which you can connect with netsend/netreceive).
There is a realtime object by which a pd~ sub-process could keep watch over Gem or whatnot, spacing out requests according to their CPU usage. That would be a pretty clunky solution but not completely unworkable.
cheers Miller
On Fri, Sep 25, 2020 at 07:14:54PM +0200, Antoine Rousseau wrote:
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://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
H
On 2020-09-25 19:33, Miller Puckette via Pd-list wrote:
but for now the only way to do that is launch two processes (which you can connect with netsend/netreceive).
but you cannot launch a 2nd Pd from within running instance (at least not with vanilla means), whereas [pd~] does allow something similar.
There is a realtime object by which a pd~ sub-process could keep watch over> Gem or whatnot, spacing out requests according to their CPU usage.
That would
be a pretty clunky solution but not completely unworkable.
you can try to use [realtime] to predict that the slave system is going to block ssonish. however, since it's really really hard to predict the future, you might be wrong, esp. if the child thread has no hard-realtime constraint.
gfmstrd IOhannes
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
On 25.09.2020 19:14, Antoine Rousseau wrote:
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 mailto: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 <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-list@lists.iem.at <mailto: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
-
Antoine Rousseau -
Christof Ressi -
Fede Camara Halac -
IOhannes m zmölnig -
Miller Puckette