-----BEGIN PGP SIGNED MESSAGE----- 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.
fgmadr IOhannes