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
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 zeroe
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
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
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
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/list
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.
Ch
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.
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 spi
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 cr
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://lists.puredata.info/listinfo/pd-list
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?
>
> T
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://lists.puredata.info/listinfo/pd-list
13 matches
Mail list logo
