[sdiy] Bunching of MIDI clock messages

[rsdio at sounds.wa.com]

> On Sep 12, 2013, at 13:01, Olivier Gillet wrote:
>> In this case, it's necessary to process Real-Time MIDI messages  
>> a.s.a.p.,
>> which means they must be handled in the interrupt - at least the  
>> critical
>> parts.
>
> There are situations in which whatever you ought to do to react to the
> MIDI message (for example, clock tick -> move to the next beat ->
> trigger a drum sample) will have to wait anyway, because, for example,
> you fill your audio output buffer by 1 ms chunks ; or refresh your
> trigger outputs at a fixed sample rate. In this case, I think, it
> makes sense to defer the processing of the realtime message out of the
> ISR.


I should have pointed out that it's not an all-or-nothing situation.  
You can do some things in the ISR and still have the option to delay  
other things that need to wait. In other words, you do not have to  
complete everything in the ISR, just set up your code so that the  
timing-critical parts happen correctly and then wait on the rest.

With regard to locking the internal timing to the MIDI clock, that  
aspect of the code should be handled in the ISR. But, as you say, the  
beat counter and sample triggers are higher-level events that may not  
be appropriate for the ISR. I still maintain that your internal clock  
timing will suffer if you don't process the MIDI clock in the ISR.

By the way, just because you create audio output buffers in 1 ms  
chunks doesn't mean that the parameters must remain constant during  
that entire buffer. There's no way to avoid a 1 ms latency in  
reacting to changes, but you can still calculate an accurate internal  
sequencer clock and have events occur with sample-accurate timing  
within each 1 ms buffer. If you don't process the MIDI clock at a  
higher resolution, then you're stuck with jitter that could be  
avoided by better code design. For example, I hope that you're not  
triggering all drum samples at the beginning of the 1 ms audio  
buffer. You'll get better timing if you use a constant 1 ms latency  
and schedule drum samples to trigger at precise points in time, with  
different sample offsets for the start of the trigger within each  
buffer. Similarly, just as you wouldn't move all drum sample triggers  
to the beginning of the 1 ms buffer, you also wouldn't assume a  
constant tempo within each buffer. The same 1 ms latency allows you  
to calculate a sample-accurate sequence clock and still map that -  
including changes in tempo - with a finer resolution than 1 ms.

But I will agree that processing of the secondary actions that are  
consequent from a real-time message are probably best handled outside  
the ISR. In other words, I would not touch any beat counters, or  
trigger samples, within the ISR. However, the primary aspect of  
syncing the internal clock to the external MIDI clock should happen  
in the ISR as soon as the real-time message occurs. All subsequent  
actions can be based on the internal clock instead of the MIDI clock.

Brian Willoughby
Sound Consulting