[PD] Using dual processor to manage 2 Pd at the same time

Matteo Sisti Sette matteosistisette at gmail.com
Tue Aug 17 17:26:09 CEST 2010

On 08/17/2010 02:11 PM, João de Brito Rocha Reis Vidigal wrote:
> Hi
> I remember reading somewhere that it is possible to have 2 Pd patches open running synched at the same time.
> This would be to manage sound and video in different patches in order not to get (or get less) glitches in sound and video.
> How do I do this?

Depends on what you mean by synched.

Well of course you need to run two instances of Pd as if it was two 
different programs.

If you mean using one patch (in one pd instance) for audio and the other 
(another pd instance) for video, which is i think the only solution to 
get both audio and video work well, I usually synchronize them by 
exchanging messages through [netsend]/[netreceive] pairs, via either TCP 
or UDP.

I would periodically send a packet from audio patch to video patch to 
tell it the current time. The video patch would then compare it with its 
own time. If the difference (measured in frames) is above a certain 
threshold, it would use some strategy to correct the situation in the 
least disturbing way depending on the application.

In the most simple case, you would detect if the difference in frames is 
 >1 (or <-1) and you would wait or skip the necessary number of frmaes.

Depending on the application, you may need much less than that (or a bit 
For example, when you have to start playing an audio and video clip at 
the same time (which may be an audio and video file or the generation of 
images and sound), you just send one message from the "master" (e.g. to 
the audio patch) to the "slave" (e.g. the video patch) so they would 
start at the same time. If the audio and videos you're playing or 
generating are short enough (few minutes) you may even not observe 
significant desynchronization. If you do, then you can resort to the 
above strategies to correct it.

All depends on the precision you need.

I usually use audio as a master and video as a slave because slightly 
affecting the speed of the video (or even skipping a frame) for 
resynching is usually much easier and more acceptable than doing the 
same on the audio side - but of course it depends.

Well I'm kind of assuming you're using GEM for the video; GEM is pretty 
good at maintaining a reliable timing; if it gets slow because of CPU 
load for a limited period of time, it tries to compensate it when it 
can, so it tends to not accumulate big errors soon.

Is this what you were talking about?

More information about the Pd-list mailing list