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? Will it be more stable if I start PD with -nogui and then PD -guiport 0?
Thanks.
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