When 2 devices are synced using MIDI Clock, why does one of the devices display a slightly different BPM than the other?
Does it mean there's a problem with the synchronization that is occurring?
Does it mean that 1 of the devices is 'right' and the other is 'wrong'?
The answer to the last two questions is very likely to be, "No". I said likely, and I'll get into a time when this actually could indicate a problem, but right now I'm going to explain why a variance in displayed BPM value is a normal part of using MIDI Clock.
There are some details about how electronic devices manage time that won't seem obvious on the surface. In relation to MIDI Sync, there are 2 important points in particular:
- First is the answer to this question: Why does MIDI Clock even exist? It's because no two electronic devices will experience time exactly the same. The reason is beyond the scope of this article or intended audience; we will just accept this as fact. Anyone who has tried knows that you can't just set two devices to the same BPM, start them at the exact same time, and expect them to stay in sync without some form of clock sharing. MIDI Clock works because one of the devices is chosen to share its timing with all the others. The device sharing its timing is called the Master Clock.
- Second is an assumption that can form that MIDI Clock is more than it actually is; that the devices using MIDI Clock are communicating a BPM value with each other. They are not.
What is MIDI Clock exactly then?
MIDI Clock is only a series of regularly spaced "pulses" (actually, messages) that are sent at a speed dependent on the desired BPM. MIDI Clock contains no other data points.
Devices can only display a BPM value by calculating it for themselves from these pulses, and only after receiving a sufficient number of pulses to do it "accurately". This is why, even though everything is running fine, sometimes when we start up a few devices using MIDI Clock sync we'll see the BPM value rise on some of the displays to reach the expected BPM Value.
When we take all that information together, then we begin to see why it is normal and expected that two devices do not have the same BPM displayed all the time. They must each relying on their own internal clock timing to make the BPM calculation. Since I explained that no two electronic devices experience time in exactly the same way, they each come to a slightly different result in their calculation. If their internal timing was exactly the same in the first place, then there would have been no need for MIDI Clock.
There's still a little more to it (and I'll get to "jitter" in a second). Each device also decides on its own how frequently it will calculate the BPM to refresh their displays, how much precision they will use in that display, and whether to round values up or down. We can easily have the Master Clock device set at 120 BPM, another device following that reports 121 BPM that has rounded up from its internal calculation of 120.5 BPM, and still another device that's reporting fluctuations between 119.6 and 120.4 BPM. Even though all this seems bad on the surface, they should all be doing fine when it comes to the actual sync. The "pulses" are still what the device should be locked into following, separate from the display calculation.
What about Jitter?
If you've been using MIDI Clock for any length of time then you've probably heard about Jitter. Jitter is irregular spacing between the pulses themselves. In an ideal system, every pulse would be sent and would arrive perfectly spaced from one another. There is no ideal though, jitter is always present, and in a serial topology, will increase the more devices the data has to merge through. When jitter becomes severe enough, you'll begin to hear fluctuations in the tempo.
How does jitter relate to the display of the BPM value? For a start, given what I've already explained, no ordinary device making quick calculations in order to simply display a BPM is a good judge of clock jitter. Even though you may see some minor fluctuations in the display of BPM on such a device, there's no way to tell from only this how much is present in the clock vs. how much is present in the routines that are being carried out to make those calculations. We already know that jitter is always present, but actually seeing a BPM fluctuating on a display can give us a false sense that there is something wrong with the clock.
Generally, I'll disregard any fluctuation that is happening within 1 BPM, which most likely means the results of the internal calculation are near the rounding threshold for that device. And since jitter is always present, the results will fluctuate over and under that threshold.
However, there are times when the BPM display could be telling us something that does indicate more of a problem. Values that swing wildly outside of 1 BPM would be an indication of the presence of high amounts of "jitter" somewhere. If that jitter is tracked to the MIDI clock being received, then perhaps better results can be obtained by distributing the signal through MIDI Splitters, bypassing pathways with the most detrimental data merges. With a little knowledge and information, signal routing is your best bet for keeping detrimental amounts of jitter in check when it develops over a longer signal chain.