[PD] Limit bandwith for MIDI output / precise metro

IOhannes m zmoelnig zmoelnig at iem.at
Tue Nov 27 10:36:07 CET 2012

Hash: SHA1

On 2012-11-26 23:29, Cyrille Henry wrote:
> Le 26/11/2012 22:38, Jean-Marie Adrien a écrit :
>> Thanks Miller !
>>> -nosound -udiobuf 5 -slepgrain 1
>> Definitely academic  :)
>> But I run intense audio on this PD instance, together with midi 
>> driving lights in real time. here are the flags  :
>> -rt  -noadc -midioutdev 1,2 -audiooutdev 2 -outchannels 8
>> phasor~ would not do it ?
> phasor~ will do provide a better clock than a metro since pd
> internal time is "perfect". your problem come from jitter between
> "pd time" and "real world time".

just to clarify:
both [phasor~] and [metro] live in an ideal world with perfect timing.
unfortunately this ideal world is not "real" (compared to your wall
clock) and has a slight jitter.
the jitter of [phasor~] is cleared by sending samples in a buffered
way to your soundcard.
with MIDI, Pd doesn't do any buffering and no synchronisation to some
external clock is done, so messages appear in bursts which you notice
as a inaccurate timing.
but the problem is really not Pd's internal timing (which is "ideal")
but the communication to the outside world.

so to answer that specific question: [phasor~] will help you, but only
if you are able to use the signal that comes out of your soundcard,
which is synced to the wall clock, in order to trigger (or do whatever
you want to do).
if you only want to use audio-objects as an internal clock source,
then you will gain exactly nothing (but lose a lot, since you
complicate things which you normally get for free).

>> maybe simply change MIDI interface to without-driver model.
> yes, that sound like a good solution.

well yes, if your midi driver is broken (that's how i interpret a
"weird stacking process"), you should probably replace that.

Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Pd-list mailing list