[sdiy] Bunching of MIDI clock messages

[Richie Burnett]

Hi all,

Many thanks for all the replies to this question.  I've only just finished 
reading them, and following the web links they included to real test results 
and discussions about their muscial significance.

There's a whole load of really useful information in there.  The main things 
I have concluded are:

1. Jitter in MIDI clock timing is quite common for several reasons, so a 
little must be accepted as an inevitable way of life,
2. The best solution is to plan to deal with the worst-case horrendously 
bunched up MIDI clocks without the receiving device loosing track of time 
and falling behind.

As several have said, it's not a matter of keeping a flag to say whether a 
MIDI clock has occurred over the last 2ms, but rather keeping a count of how 
many have occurred.  Then process the outstanding timer ticks at the 
absolute earliest opportunity.

This thread has also raised some interesting discussions about how much MIDI 
processing of things like MIDI clock and running-status should be done in 
the UART receive ISR, and how much of the work in the main program block. 
Some good arguments that will let me weigh up the pros and cons of both 
methods for my particular application.

I had originally intended to strip the MIDI clock messages out of the 
received data stream inside the ISR (and increment a "MIDI clock events 
outstanding" counter.)  The reasoning behind this was to deal with the "MIDI 
clock appearing in the middle of another MIDI message" problem that Paul 
Maddox mentioned.  I'd also intended that the same ISR keep track of the 
running status and only write complete MIDI messages into the receive buffer 
with the running status bytes reinstated at the start.  (This appears to be 
how Midibox's MIOS works.)  But after some offlist discussions with Olivier 
Gillet he's convinced me to keep the Rx ISR lean and just throw everything 
into a ring buffer to be dealt with and decoded at the earliest opportunity 
in the main program.

Regarding the "TEMPO PLL" idea, it would scare me a little thinking about 
how long the phase-locked-loop might take to settle.  I've designed several 
analogue PLLs before and think that it might be hard to simultaneously 
achieve:

1. Locking at the right tempo (zero frequency error)
2. Locking in time with the downbeat of the master (zero phase error)
3. Reduction of clock jitter
4. Fast response to tempo changes.

I think i've resigned to the fact that if a sequencer sends out a burst of 
bunched up MIDI clocks everything is going to sounds shite during that time, 
(and that's down to a deficiency in that particular sequencer at that time.) 
I just want to make sure that my product doesn't get thrown out of time by 
this situation in such a way that it doesn't recover.

-Richie,

PS. Regarding the jitter, swing thing in the early Roland products with 2ms 
CPU interrupt, this is a different discussion topic.  However, I watched 
Colin Fraser demonstrate this with his TB-303 at Synth DIY last year and the 
shuffling pattern is definitely very easily audible for certain tempo 
settings.