> I understand your point but it is essential the Cirklon
> gracefully handle timing data from a PC regardless of how
> sloppy you think it is. If nothing else, it would be nice if
> the Cirklon could act as a clock filter of sorts, ignoring
> the jitter like the P3 and passing a cleaned version upstream.
> Even if this introduces slight latency, that is more easily
> fixed in the DAW than timing that is all over the place.
Cirklon already does this for MTC.
Unfortunately it's not practical for MIDI clock, because you don't have any
prior knowledge of when the ticks are supposed to be arriving.
The instantaneous tempo conveyed by MIDI clock is the reciprocal of the
period between the last two clock ticks.
Each clock tick defines the instant of each 24th of a quarter note.
The inevitable timing jitter imposed on MIDI clock bytes can therefore be
considered a 'noise' signal, overlaid on the tempo information.
You can't filter it out without then having a slow step response to a change
in tempo.
If you have a sudden change to a higher or lower tempo at the start of a
bar, the notes coming from a slaved device that is smoothing out the tempo
will be obviously out of time.
It may be possible to work around that using a window around the expected
time of a clock tick for the current tempo, and defeating the smoothing if a
significant change in the tick period is detected.
But given the level of jitter you get from a PC MIDI interface (2 to 3 ms is
not atypical), you don't have much leeway when the tick period at 120bpm is
only 20ms.
For MIDI timecode the situation is much better - the quarter frame ticks run
at a permanently fixed rate.
When Cirklon slaves to MIDI timecode, it generates its own internal timecode
and synchronises by comparing both the phase and frequency of its internal
tick to a heavily filtered version of the incoming MTC ticks.
The result is a timebase with far less jitter than the master source.
This image shows what I mean:
http://www.sequentix.com/cirklon/cirklon-mtc-filt.jpg
The upper trace shows a 100Hz square wave on an audio track (cyan/yellow),
along with a pulse indicating the end of a MTC quarter frame tick at 25fps
(= 100Hz tick) from Cubase on a quad core PC with a USB MIDI interface.
You can see that the QF ticks are spread over a range of roughly 1 to 4ms
late (it's a persistent scope trace over a long period).
The lower trace shows the same audio signal, along with a pulse being
generated by Cirklon from its internal timecode tick, synchronised to the
filtered version of the PCs tick.
Jitter on that pulse is down to about +/- 500us.
I made these traces before I implemented a linear offset, which allows the
average latency of the regenerated ticks to be tuned out, lining the centre
of Cirklon's tick precisely in line with the audio reference.
Best regards,
Colin Fraser
Sequentix Music Systems Ltd
http://www.sequentix.com