[sdiy] Bunching of MIDI clock messages

[rsdio at sounds.wa.com]

Chris and Tom both have it right. MIDI timing messages should not be  
polled; they should be handled upon reception in the interrupt  
handler. That's the whole point about System Real-Time messages;  
they're 1 byte long so that they can be placed even in the middle of  
a Note On or Pitch Bend message without disturbing running status.  
MIDI was designed with this implementation in mind.

On the sending side, your MIDI timing mechanism should be able to  
place a Real-Time message in the very next UART byte (so long as it  
doesn't obliterate a byte that's in the process of being  
transmitted). On the receiving side, your interrupt routine should  
handle the Real-Time message in a quick, non-blocking manner without  
even placing the byte in your queue.

Longer messages like the System Common and Channel Messages must go  
in the queue, and that includes Song Position Pointer.

Brian Willoughby
Sound Consulting


On Sep 11, 2013, at 12:23, Tom Wiltshire wrote:
> That's how I did it. Seemed reasonable to me. I would imagine other  
> people have had the same idea as us both. I have to admit that  
> partly my motivation was to avoid repetitive MIDI clock and other  
> real-time data clogging up the MIDI input buffer, rather than any  
> high-minded sense of timing accuracy!
>
> Tom
>
> On 11 Sep 2013, at 13:39, ChristianH <chris at chrismusic.de> wrote:
>> Wouldn't it be more reasonable to immediately increment some internal
>> time code counter right from the MIDI reception interrupt handler,
>> rather than checking for it at some other time after passing  
>> through a
>> FIFO? Isn't that what real-time messages are about?
>> Ok, probably some locking mechanism will be needed to prevent
>> concurrency issues.
>>
>> Chris
>>
>> On Wed, 11 Sep 2013 12:32:31 +0100 rburnett at richieburnett.co.uk  
>> wrote:
>>> How common is "bunching up" of MIDI clock messages due to erratic
>>> transmission out of sequencers?
>>>
>>> For example, if I check for the reception of a MIDI clock message  
>>> every
>>> 2 millisconds in a receiving instrument is that sufficient?  (In  
>>> theory
>>> 2ms polling rate should be sufficient to support tempo up to 1250  
>>> BPM
>>> provided the clock events arrive with even spacing!)  Or do you  
>>> think I
>>> should cater for the possibility of receiving as many as seven MIDI
>>> clock events transmitted "nut to butt" over my 2 millisecond polling
>>> period!?!?
>>>
>>> I know the MIDI specifications says that MIDI clock messages are  
>>> to be
>>> transmitted with even spacing at the average tempo rate, but I don't
>>> think i've ever seen a maximum jitter specification anywhere?  (I  
>>> can
>>> just imagine sequencer software getting preempted in a Windows
>>> environment, and later transmitting all of the overdue MIDI data  
>>> in an
>>> intense burst.)
>>>
>>> Any thoughts/experience on this?
>