[sdiy] MIDI Clock sync advice

Tom Wiltshire tom at electricdruid.net
Fri Mar 8 23:52:22 CET 2024


Hi Brian,

Yes, thanks. I'm not sure at exactly what point I realised that the whole design of the MIDI protocol was arranged around low-power processors (the only type they had at the time!) but it might well have been when I started thinking about realtime messages. The structure of the protocol makes it pretty clear that the best way to deal with them is to strip them out in the interrupt so that they get the most time-accurate handling and also don't get in the way of the parsing of other messages. It's a really clever design.

My current project is in C on a PIC 18F processor, so it's pretty "bare metal". I've got this far on a 16F chip, but I've decided to give it an upgrade because the 18F chips offer many significant enhancements, particularly DMA for data transfers and the hardware multiply.

I *was* thinking of mirroring hardware +5V triggers (for analog drum circuits) as MIDI note output. Obviously the timing won't be as tight on the MIDI output, but that's just the nature of the beast. All the hardware triggers can be accurately synchronised to all rise together, which is clearly impossible with MIDI Note On messages which take roughly 1msec for the first one and 600msecs for subsequent ones (because of running status). In practice, most human ears aren't even *that* good. You'd be able to hear the latency if you played the internal sound sources against samples of them triggered via MIDI, for example, but I was mostly thinking of this as a way to use the sequencer to trigger external sound modules with *different* sounds, so I don't see it being too much of a problem. Perhaps if I get that far I could even add in a bit of "pre-compensation" so the MIDI notes start going out slightly ahead of time so that although some might be early, the worst of them are never so late? That might need to account for how many notes were about to be played, which all starts to get more complicated. There's a lot of ways to deal with this stuff, depending how involved you want to get.

Anyway, many thanks for your thoughts.

Tom


==================
       Electric Druid
Synth & Stompbox DIY
==================



> On 8 Mar 2024, at 21:33, brianw <brianw at audiobanshee.com> wrote:
> 
> Hi Tom,
> 
> You may have already designed with the following in mind, but I highly recommend taking advantage of the design of MIDI to handle clock messages in an efficient manner.
> 
> You will note that all of the System Real Time messages in MIDI are single-byte. This allows you to handle timing inside the interrupt for the serial input, without even involving the usual queue of MIDI data. Basically, your interrupt handler should extract all of the System Real Time messages out of the stream and handle them immediately, tightly integrated with your local time reference. All the remaining MIDI messages (that aren't System Real Time) can then go into the queue for non-interrupt processing.
> 
> This will require that you write your firmware as "bare metal" or at least using a Real Time Operating System (RTOS). Admittedly, I'm not familiar with the support for MIDI in higher level operating systems with serial drivers, so perhaps there are correct solutions out there.
> 
> In any case, having a good design for interrupt handling, and writing the code so that System Real Time messages are processed instantly, will ensure that your derived clock will be as accurate and stable as possible. Any slack here will result in more slop on your resulting clock.
> 
> Brian WIlloughby
> 
> p.s. If your device also sends MIDI, then it will help to similarly design your MIDI output code to prioritize MIDI sync output without any latency due to queuing. You may end up needing a queue, but keep the sync queue separate from the non-real-time queue. But, being a drum sequencer, maybe you don't have MIDI output?
> 
> 
> On Mar 8, 2024, at 7:10 AM, Tom Wiltshire 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
>> 
>> ==================
>>      Electric Druid
>> Synth & Stompbox DIY
>> ==================
> 




More information about the Synth-diy mailing list