[sdiy] MIDI Clock sync advice

[brianw]

It's quite common to use a PLL or DPLL (digital phase-locked loop) to generate a much higher frequency locally, based on a lower frequency external clock reference.

The key is to generate the desired high frequency as a primary clock, but then divide that primary clock down to match the rate of the incoming reference. The PLL then tweaks the high frequency primary clock until the divided-down clock matches the phase and frequency of the incoming reference.

e.g. I designed a DSP-based product that ran on an internal 108 MHz clock, but which was fed by a mere 12 MHz crystal. The chip simply created the 108 MHz clock, divided by 9 to derive a 12 MHz intermediate clock, and then used the DPLL to sync that with the 12 MHz crystal oscillator.

This technique can be used to work with 96 ppqn or even higher, without being limited to the 24 ppqn rate of MIDI clocks - and especially not limited to 12 ppqn.

The challenge is to balance a fast "time to lock" versus smoothing. Generally, the more smoothing that is applied, the longer it takes to lock to a new clock. I haven't researched this fully, but a PID might help with that tradeoff.

Brian

p.s. I don't know whether Ben's approach is compatible with a PLL.


On Mar 8, 2024, at 8:33 AM, Benjamin Tremblay wrote:
> This has been bothering me as the biggest blocker preventing me from adapting vintage drum machines to work with midi. 24ppqn can only be used to generate a 12ppqn square wave.  Attempting to synthesize a higher frequency may work in some cases and fail in others. I think the whole strategy of keeping 2 asynchronous clocks in sync is insane.   Clocks have to be reliable. This is not a frequency multiplier/wave shaper module for a vco. I’m not just trying emphasize the *2 harmonic in a pitch. The clock must work as expected, always.
> 
> Benjamin Tremblay
> 
> On Mar 8, 2024, at 11:24 AM, Ben Stuyts wrote:
>> Hi Tom,
>> 
>> I have used something like 2) for my day job, often on low-end controllers: y(t) = a * x(t) + (1-a) * y(t-1). With a in <0..1]. Everything then scaled so as to fit everything in 8/16 bit ints.
>> 
>> One thing I sometimes add to this to prevent lag (and startup condition) to this is to check for large steps between x(t) and y(t-1). If so, just use y(t) = x(t) and continue from there.
>> 
>> Ben
>> 
>> On 8 Mar 2024, at 16:10, Tom Wiltshire <tom at electricdruid.net> wrote:
>>> Hi All,
>>> 
>>> Has anyone got any experience dealing with writing software to sync to MIDI clock that they can share?
>>> 
>>> I'm working on a drum sequencer which will run at 96PPQN, and it'd be nice if it could sync to incoming 24PPQN MIDI Clock messages.
>>> 
>>> I can see a couple of ways to do this:
>>> 
>>> 1) Some sort of PID controller, where we compare the internal timing and the incoming clock timing and derive some error signals.
>>> 2) IIR filtering. We measure the time between incoming clocks and then use an IIR filter to provide some averaging and smoothing. We then set the internal clock based on the filter's output.
>>> 
>>> (2) seems like the simpler approach. Clearly it will introduce some lag when changing tempo, but I'm not sure I see this as a fault - smooth tempo changes could be a feature. And depending on how much filtering is required, that lag might actually be quite short. What's a reasonable time constant for such a thing?
>>> 
>>> How has this been approached in the past? I know that I'm not the first person to do this, so I'm just trying to avoid re-inventing the stone-age MIDI wheel!
>>> 
>>> Many thanks for any ideas/pointers offered,
>>> Tom