[PD] metro drift

Nicola Pandini via Pd-list pd-list at lists.iem.at
Sun Jul 20 16:06:56 CEST 2014


> On Mit, 2014-07-16 at 14:08 +0200, Nicola Pandini via Pd-list wrote:
>> Hi,
>> I made a patch that uses metro to keep the sync between sequencers and
>> other instances of the patch. I also use this patch to start, stop and
>> set the tempo of SooperLooper. I only use this patch to do MIDI stuffs
>> (with options -noaudio -alsamidi)
>> Sometimes, when the metro is running and I open a patch full of canvas
>> and nbx, the metro freezes for a couple of seconds, and so Pure Data and
>> SooperLooper lose the sync.
>> Is there a way to avoid this?
> There is probably a way to circumvent the problem. Different audio
> backends behave differently. I can't tell anything about Windows or Mac
> OS X, but on Linux you could use ALSA as the audio backend in order to
> keep Pd in sync with real time. This won't help avoid xruns, of course,
> but when xruns occur, Pd will catch up (assumingly by just skipping a
> few blocks) until it is in sync with real time again.
>
> The situation with JACK is different. When an xrun occurs, Pd freezes
> until the blocking operation is finished and then Pd is behind real
> time. I don't know about CoreAudio, MMIO or ASIO. Probably one of them
> behaves similar to ALSA?
>   
>> Will it be more stable if I start PD with -nogui and then PD -guiport 0?
> I don't understand what you're trying to achieve with that, but it seems
> to me it won't help. The key word here really is 'blocking operations'.
> Try to avoid them. Do not load large patches, don't load soundfiles,
> don't do any [1000000(-[until] stuff.
>
> Roman

Thank you Roman, I'll try to use alsa as audio backend.

-- 
Nicola




More information about the Pd-list mailing list