It has a specifiable delay in blocks, minimum 2 I believe.
cheers Miller
On Wed, Apr 06, 2016 at 02:52:10AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi list,Does [pd~] have a one-block delay? Thanks,Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
You can get it down to one block. You can try zero, but it will crash; maybe that's a bug (that is, maybe it shouldn't honor the request with an attempt).
The default is five blocks of delay, if I remember correctly.
On Wed, Apr 6, 2016 at 12:00 AM, Miller Puckette msp@ucsd.edu wrote:
It has a specifiable delay in blocks, minimum 2 I believe.
cheers Miller
On Wed, Apr 06, 2016 at 02:52:10AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi list,Does [pd~] have a one-block delay? Thanks,Jonathan
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
Hi,
me and Matt discussed [pd~] some time ago. The default fifo blocks is 5; anyway (line 634 of pd.c) [pd~] doesn't check arguments, so you can put values as you want, like fifo 0 or fifo -1... but it doesn't like :)
Best regards.
Marco
2016-04-06 6:22 GMT+02:00 Matt Barber brbrofsvl@gmail.com:
You can get it down to one block. You can try zero, but it will crash; maybe that's a bug (that is, maybe it shouldn't honor the request with an attempt).
The default is five blocks of delay, if I remember correctly.
On Wed, Apr 6, 2016 at 12:00 AM, Miller Puckette msp@ucsd.edu wrote:
It has a specifiable delay in blocks, minimum 2 I believe.
cheers Miller
On Wed, Apr 06, 2016 at 02:52:10AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi list,Does [pd~] have a one-block delay? Thanks,Jonathan
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
Some more sanity checks: Problem with throwing gem patch in [pd~] is that the block synchronization is way too granular for video processing. In other words, you could have gem object chain calculations that will finish in time to show the next video frame, but they don't finish in the time it takes Pd to compute a 64-sample audio block. This leads to freezes or dropouts in the parent process that is processing audio. Similarly, if you switched roles-- gem stuff in parent process, audio in [pd~]-- you'd still have a problem. While the audio in [pd~] may get computed on time, the video computation in the parent process may take too long. So the audio is sitting there waiting patiently, but the parent doesn't get done with its computation in time to call it by the deadline. Is this essentially correct? If so, couldn't this issue be addressed by setting a larger dsp-block size for the sub- process? -Jonathan
On Wednesday, April 6, 2016 3:14 AM, Marco Matteo Markidis mm.markidis@gmail.com wrote:
Hi, me and Matt discussed [pd~] some time ago. The default fifo blocks is 5; anyway (line 634 of pd.c) [pd~] doesn't check arguments, so you can put values as you want, like fifo 0 or fifo -1... but it doesn't like :) Best regards. Marco 2016-04-06 6:22 GMT+02:00 Matt Barber brbrofsvl@gmail.com:
You can get it down to one block. You can try zero, but it will crash; maybe that's a bug (that is, maybe it shouldn't honor the request with an attempt). The default is five blocks of delay, if I remember correctly. On Wed, Apr 6, 2016 at 12:00 AM, Miller Puckette msp@ucsd.edu wrote:
It has a specifiable delay in blocks, minimum 2 I believe.
cheers Miller
On Wed, Apr 06, 2016 at 02:52:10AM +0000, Jonathan Wilkes via Pd-list wrote:
Hi list,Does [pd~] have a one-block delay? Thanks,Jonathan
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Le 06/04/2016 22:01, Jonathan Wilkes via Pd-list a écrit :
Some more sanity checks:
Problem with throwing gem patch in [pd~] is that the block synchronization is way too granular for video processing. In other words, you could have gem object chain calculations that will finish in time to show the next video frame, but they don't finish in the time it takes Pd to compute a 64-sample audio block. This leads to freezes or dropouts in the parent process that is processing audio.
Similarly, if you switched roles-- gem stuff in parent process, audio in [pd~]-- you'd still have a problem. While the audio in [pd~] may get computed on time, the video computation in the parent process may take too long. So the audio is sitting there waiting patiently, but the parent doesn't get done with its computation in time to call it by the deadline.
Is this essentially correct?
pd and pd~ are syncronize at audio rate, but a buffer allow to control the way to computation of the 2 can be out of sync. i.e : using a fifo of 5 blocks (less than 7ms), the 2 process can't be desynchronized more than 7ms...
If the Gem patch and the audio patch can both run in real time on there respective thread, then no process will wait the other if the fifo is large enough.
When using Gem in the pd~, i would use at least double the time between 2 images for the fifo buffer. i.e. at 50fps, there is 20ms between images, so i'll try a 40ms buffer. At 48Khz, this represent a minimal fifo of 30. double that for 25fps rendering.
If so, couldn't this issue be addressed by setting a larger dsp-block size for the sub- process?
i don't understand why a larger dsp block size would change anything. did you also do audio computation in the pd~?
be also aware that communication between pd and pd~ is cpu hungry.
cheers c
-Jonathan
On Wednesday, April 6, 2016 3:14 AM, Marco Matteo Markidis mm.markidis@gmail.com wrote:
Hi,
me and Matt discussed [pd~] some time ago. The default fifo blocks is 5; anyway (line 634 of pd.c) [pd~] doesn't check arguments, so you can put values as you want, like fifo 0 or fifo -1... but it doesn't like :)
Best regards.
Marco
2016-04-06 6:22 GMT+02:00 Matt Barber <brbrofsvl@gmail.com mailto:brbrofsvl@gmail.com>:
You can get it down to one block. You can try zero, but it will crash; maybe that's a bug (that is, maybe it shouldn't honor the request with an attempt). The default is five blocks of delay, if I remember correctly. On Wed, Apr 6, 2016 at 12:00 AM, Miller Puckette <msp@ucsd.edu <mailto:msp@ucsd.edu>> wrote: It has a specifiable delay in blocks, minimum 2 I believe. cheers Miller On Wed, Apr 06, 2016 at 02:52:10AM +0000, Jonathan Wilkes via Pd-list wrote: > Hi list,Does [pd~] have a one-block delay? > Thanks,Jonathan > > _______________________________________________ > 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 <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
Le 06/04/2016 23:42, Jonathan Wilkes via Pd-list a écrit :
be also aware that communication between pd and pd~ is cpu hungry.
Is this the overriding reason why someone would prefer running two instances of Pd manually and communicating over netsend/receive?
not really, since you can use netsend / netreceive between pd and pd~.
Running 2 instance of pd communicating with network socket is very different than using pd/pd~
since the 2 pd are not synchronized, the communication is not sample accurate. This is not a problem for most applications. the good thing is that if one pd is locked, it will not lock the other. i.e : the rendering will not cause dropout in the sound, but desynchronization may appear.
cheeers c
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Running 2 instance of pd communicating with network socket is very different than using pd/pd~
Right, but like you said if you have video meeting its deadlines in one process and audio meeting its deadlines in another process, the pd/pd~ approach should meet the user's needs. Furthermore pd/pd~ offers a better user experience (i.e., run a single patch and let Pd spawn the 2nd automatically). Given that I'd think most people would be using it for simple divisions of audio/video work, but messages to the list suggest otherwise. So I'm wondering if the increased cpu usage of pd~ is significant enough to be driving users to the worse UX in order to get the efficiency. -Jonathan
Le 07/04/2016 06:58, Jonathan Wilkes via Pd-list a écrit :
Running 2 instance of pd communicating with network socket is very different than using pd/pd~
Right, but like you said if you have video meeting its deadlines in one process and audio meeting its deadlines in another process, the pd/pd~ approach should meet the user's needs.
Furthermore pd/pd~ offers a better user experience (i.e., run a single patch and let Pd spawn the 2nd automatically). Given that I'd think most people would be using it for simple divisions of audio/video work, but messages to the list suggest otherwise.
really? i should send more mail then. I'm a big fan of pd~.
So I'm wondering if the increased cpu usage of pd~ is
significant enough to be driving users to the worse UX in order to get the efficiency.
communication between pd and pd~ is the only drawback of pd~ usage in my opinion. but it's a sample accurate communication. something that can't be done otherwise. if you need this precision, you don't have any choice.
My use of pd~ is not for splitting audio and video, but mostly to split heavy physical modelling and audio-video rendering. physical modelling use and generate lot's of data that can't go throw pd~ inlet and outlet, that where the shermem external become useful.
cheers c
-Jonathan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
cyrille henry -
Jonathan Wilkes -
Marco Matteo Markidis -
Matt Barber -
Miller Puckette