Hi,
When using pd~ with -fifo 1, do you get a delay of 1 block like in throw/catch scenario?
Thanks!
fd
fdch.github.io
That _should_ be correct.
fifos less than 2 are probably inefficient (but I dn't know that for sure).
cheers Miller
On Thu, Sep 24, 2020 at 06:37:42PM -0300, Fede Camara Halac wrote:
???Hi,
When using pd~ with -fifo 1, do you get a delay of 1 block like in throw/catch scenario?
Thanks!
fd
fdch.github.io
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
Thanks, Miller.
Yes, it seems that is the case. I attach an example that shows the delayed block(s).
What do you mean inefficient? I do not see a drastic change in cpu usage on the very basic adc-to-dac example subprocess I include here.
As a side note, I noticed that loading -fifo 0 seems to crash pd !
Best,
ffdd
On Thu, Sep 24, 2020 at 5:42 PM Miller Puckette msp@ucsd.edu wrote:
That _should_ be correct.
fifos less than 2 are probably inefficient (but I dn't know that for sure).
cheers Miller
On Thu, Sep 24, 2020 at 06:37:42PM -0300, Fede Camara Halac wrote:
???Hi,
When using pd~ with -fifo 1, do you get a delay of 1 block like in
throw/catch scenario?
Thanks!
fd
fdch.github.io
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!...
I think that having a small buffer for the subprocess is not a problem, as long as the buffer (= delay) of the parent process is large enough to absorb the CPU spikes of the subprocess.
If you use a single buffer for the subprocess, then the parent process practically has to absorb all CPU spikes.
Of course, it depends on the actual patch. For example, if the subprocess has several large FFTs (which are notorious for producing CPU spikes), it makes sense to use a higher buffer size to prevent it from blocking the parent process. If the subprocess has a fairly regular CPU load, you can get away with the minimal buffer size, even if the parent process has a rather small buffer size.
Christof
On 25.09.2020 00:41, ffdd cchh wrote:
Thanks, Miller.
Yes, it seems that is the case. I attach an example that shows the delayed block(s).
What do you mean inefficient? I do not see a drastic change in cpu usage on the very basic adc-to-dac example subprocess I include here.
As a side note, I noticed that loading -fifo 0 seems to crash pd !
Best,
ffdd
On Thu, Sep 24, 2020 at 5:42 PM Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
That _should_ be correct. fifos less than 2 are probably inefficient (but I dn't know that for sure). cheers Miller On Thu, Sep 24, 2020 at 06:37:42PM -0300, Fede Camara Halac wrote: > ???Hi, > > When using pd~ with -fifo 1, do you get a delay of 1 block like in throw/catch scenario? > > Thanks! > > fd > > fdch.github.io <http://fdch.github.io> > > > _______________________________________________ > Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list > UNSUBSCRIBE and account-management -> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!Uyv-HqXmCoj0l9209QG7_r5nfJVd8i8hyj0jSDRm6FzZv6t-9DKLtwT6Zaba$
-- fdch.github.io http://fdch.github.io
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Christof,
Thanks! I am a bit confused, though. Is the "buffer (=delay)" the -fifo or are you talking about block sizes in parent and subprocess?
Best,
ffd
The "delay" setting controls the ringbuffer size of the parent process (only true if not in "callback" mode). The "-fifo" argument for [pd~] controls the ringbuffer size of the subprocess.
Any CPU spikes which the subprocess ringbuffer can't handle will "spill" over to the parent process.
Christof
On 25.09.2020 04:14, Fede Camara Halac wrote:
Hi Christof,
Thanks! I am a bit confused, though. Is the "buffer (=delay)" the -fifo or are you talking about block sizes in parent and subprocess?
Best,
ffd
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list