Midipal clock - how precise?

Just wondering how precise the tempo is for the clock in midipal apps Sequencer, Synclatch, Clock, Drums, Arpeggio, Delay.

Not that I have noticed any problems so far, but in particular I might like to use Clock app as a master clock for my setup, on occasions that I want a very precise tempo - if it is particularly accurate/jitter free.

Its accurate as the Quartz itself so its typical ±30ppm which is the overall precision.
The jitter is up to the Hardware which is so simple i don’t expect any, the
wow and flutter the MIDIpal produces is dependent on the Software it runs and should be next to nothing (as i suspect Olivier to make things with a bulletproof timing…).
So the whole thing should be better than most Windows based Systems and as good as a OSX/eMagic Unitor combo or an MPC.

What do you compare it with though? Everything varies slightly. You would probably need an atomic clock to compare it with.

Not really… you can actually hear if a Sequencer/MIDIinterface has a “tight” timing or not. Tight is a MPC (any), totally untight is AbletonLive running under Win7 triggering Drums on an E4XT via an Novation ReMote 49 SLs MIDI Interface. If you measure this it will be well within Milliseconds, but you can here theres something wrong - it simply istn tight. Its like comparing your best Drummer Buddie when drunk with Simon Phillips when recording. So yes - timing does matter to me.

But trying to Sync the Ableton/Win7/E4XT/Novation Mess above with a MIDIpal wouldn’t make it better i guess…

It is easy to roughly measure by recording audio from a known accurate slave device, anyway I just did this and the widest variation between clocks was 48 samples at 44.1khz so around 1.088ms - pretty damn good! Taking into account that the slave would be contributing some of the deviation, certainly good enough for my needs :slight_smile:

1ms is quite good - 9ms is quite suboptimal…

Well there’s “tight” timing, how much latency and jitter there is, then there’s accurate which means how accurate is the tempo.

Two different things :slight_smile:

Colin Fraser, maker of Cirklon, wrote a nice post on the Sequentix forum as answer to the question if anyone knows how the Cirklon compares to other machines for timing accuracy. I’m just copy and pasting here, but I found it an interesting read. :slight_smile: Hope he doesn’t mind…

I feel an essay coming on... Before starting work on Cirklon, I did a fair amount of research into timing, so I think I have a pretty good take on it. I'm open to debate, so long as it's based on empirical evidence (e.g. double-blind listening tests) and not just an assumption that a linear improvement in timing precision leads to a linear increase in perceived tightness.

There are two important factors in the tightness of a sequencer - the internal accuracy of the timing of output events, and the minimum transmission latency.
The most significant of these for a hardware MIDI sequencer is always going to be transmission latency.
I found timing differences between multiple notes that are supposed to be playing at the same time are much more audible than variations in the timing of a regular single note.
MIDI takes just under 1 millisecond to send a note message, or 0.64ms with running status.
MIDI gets an unfair amount of blame for bad timing, IMHO. A 0.64ms timing spread between ‘simultaneous’ notes is not going to be audible unless the attack times of the sounds are close to or shorter than the delay.
When you’re dealing with a synth sound, the oscillators across different voices at different pitches will be at different points in their phase, so even at super fast attack times there would be a variable amount of note-on click across different voices that will mask MIDI timing spread.
Practically speaking, many MIDI synths add more processing latency than the MIDI delay anyway.
Where MIDI does fall down is with percussive sounds. Triggering simultaneous drum sounds with varying MIDI delay will often lead to phasing effects changing the character of the combined sound.
Even if it’s not audible as a timing error, you can hear it as a tonal change.
That’s why I trigger my drums with the dedicated drum trigger output with synchronised trigger pulses (boards will be available soon).
The way to get the best timing from MIDI is to use as many MIDI busses as possible and spread instruments across them.
The fewer notes that are being sent on each MIDI port, the lower the average delay on each one is, and the closer together all the notes on one beat will be.
For a sequencer with multiple ports, you should start with a single instrument on each port, and when/if you need to start doubling up, try to mix a synth that is more often used for pads or less attacky sounds, with a monosynth that might be doing snappy or precussive stuff. And keep the monosynth on a track with higher processing priority. On Cirklon, tracks are processed in ascending numerical order.
Assuming the internal timing accuracy is not a factor, I think it fair to say that in real terms (i.e. actually making music with it, as opposed to doing a laboratory analysis of timing), the MIDI sequencer with the best timing accuracy is the one with most independent MIDI outs. That puts Cirklon ahead of most other hardware sequencers.
I’m not aware of anything with more than 5 ports other than the Yamaha QX1, or a custom MIDIBox sequencer.

Coming to the internal timing accuracy, there are different approaches to timing events in a sequencer, and the approach used will affect the underlying timing precision.
I’ve seen the results of the timing tests on Inner Clock’s site, and there’s some very useful information there.
But, given that we’re using MIDI, and listening to the results with human ears, there’s a point at which improving timing accuracy offers no further benefit.
A typical pair of human ears will be separated by about 6 inches.
The extra distance that sound must travel to the far ear, if it is coming directly from one side of the listener, is about 8 inches - the length of the path the sound wave takes round your head.
This leads to what is called ITD - interaural time delay. It is in the order of 0.75ms for a typical head.
This time delay is used by the auditory system to extract spatial information.
That’s why a binaural (dummy head) recording sounds so much more 3-dimensional than stereo - our ears use both amplitude difference and ITD to localize sound.
Stereo mixing usually only uses amplitude.
The upshot of this is that rhythmic deviations around or below your maximum ITD can not be perceived as a temporal difference.
ITD information is encoded as spatial information before it passes up the auditory system, so the perceptual timing resolution at higher levels cannot exceed it.
You can demonstrate this very easily. Put your head halfway between a pair of speakers, with a rhythmic sound playing.
Move your head 6 inches nearer to one of the speakers.
Your head is now 1 foot closer to one of the speakers than the other, so you are hearing the sound from the nearer speaker almost 1 millisecond in advance of the other speaker.
Did you hear a spatial change, or did you hear the drum sound coming from the nearer speaker with an echo in the other speaker ?
I did various a/b listening tests to see what level of rhythmic error I could reliably detect in a rhythm, and I couldn’t reliably identify an error of 1 ms.
Note that this is purely the ability to discriminate a timing error in a regular pattern of isolated sound events.
On that basis, I set the heart-beat period of the Cirklon sequence engine at 250us - at least 4 times better than I could hear.
Tempo is calculated to a much higher precision (1/65536th ms), but the timing of individual events is quantised to a 250us window, such that typical timing jitter is in the order of 125us before MIDI delay.
If you’re interested in testing your own hearing, I can upload some test sounds and point you to the WinABX double-blind audio testing software.

The CVIO output on Cirklon has a much higher bandwidth than MIDI.
For that reason, I chose to deliberately delay sending of the data to the CVIO until after the MIDI data had a headstart.
This is so that a MIDI receiving instrument with minimal processing latency is likely to be in closer sync with any gates being triggered on CVIO on the same tick.
The change of state of the CVIO gate outputs is synchronised across all outputs for the same clock tick, since the simultaneous triggering of sounds was found to be so important.

MidiPal clock the most accurate and stable clock source among the ones I’ve tested.

Here are some numbers for clock accuracy and stability expressed as average BMP and standard deviation over 96 clocks (4 beats). All devices were set to 40, 120 and 240 BPM:

MidiPal: 39.9/0.1% 120.1/0.3% 240.5/0.2%
Alesis HR16: 40.7/1.5% 121.2/0.7% 242.3/1.2%
Alesis SR18: 39.9/0.1% 120.0/0.3% 240.3/1.0%
DSI Evolver: 39.9/0.2% 120.1/0.5% 240.4/0.9%
Korg Z1: 40.1/0.2% 120.1/0.5% 240.2/1.2%
Roland Gaia: 39.9/0.9% 120.1/1.8% 240.7/4.7%

The test was performed using Midi Clock Tester (a one off project I did to teach myself Atmel programming) calibrated with very accurate lab function generator.

No surprise with the GAIA but I’m a bit shocked by the Evolver

Are those SR18 figures correct? The 240.3/1.0% must have a typo?

It’s not a typo, i just repeated the test and got the the same result.

SR18 clocks seems to be pretty tight up to 180 BMP, however after that stability slowly degrades reaching 1.5% at 300 BPM.

You have midipal as 240.5/0.2% and SR18 as 240.3/1.0% so a 0.3 bpm deviation would not be a 1% error would it, more like 0.1 something or am I misunderstanding you numbers?

The second number (percentage) is a sqrt( 1 / (N-1) * sum( (Xn - Xave)^2 ), i.e. how close clock values are grouped around their average value. This characterizes clock stability as opposed to clock accuracy, i.e. how close are the clock values to 240 BMP.

Ah, I see - thanks for clarifying.

Hi,

First post here. I’m semi-curious how accurate my “good 'ol” Yamaha RM1x is. I’ve been using as my master clock for years.

Regarding the Evolver, are you sure the “slop” setting was set to zero? The Evolver can intentionally add inaccuracies to give a more “analog” feel. I’ve never noticed if this is just pure OSC slop or more.

Very cool, thanks kvitekp (fancy seeing you here, still have your PC1600?). And high Daren also!

One thing that would be interesting for me - hoping you have Ableton Live, I would love to see a test of its MIDI clock output. I appreciate that it might be a function of the MIDI interface you have in between, but still… Also if you have any other major DAW platforms…

@phreon – I don’t have Yamaha RMx1 but plan to get one off ebay some day, will let you know… Evolver’s OSC slop does not affect sequencer clock.

@dnigrin – hey, good to see you too :wink: my PC1600 is somewhere in storage on the other side of the globe :slight_smile: I don’t have Ableton Live, still using Cubase SX. The best clock I could achieve is with Win XP based desktop, trimmed down to absolute minimum of running services, with disabled ACPI and every device using dedicated interrupt number, running midisport 8x8 – it has standard deviation 1.5%. Typical modern PC running Windows 7 is around 3-4%

Thanks - that’s pretty bad. I’m primarily Mac-based, I wonder if the situation is any better there… My personal experience with the Ableton clock is that it is not very good…

Hi Dan!

kvitekp - Might be interesting to use the midipal bpm monitor on the SR18, HR16, Z1, Evolver and Gaia to see if it reports the same errors.