[LAD] [Bulk] Re: Midi Beat Clock to BPM

Tim E. Real termtech at rogers.com
Sat Nov 1 20:55:25 UTC 2014

On November 1, 2014 08:10:30 PM Clemens Ladisch wrote:
> hermann meyer wrote:
> > I try to fetch the bpm from the Midi Clock, and stumble over "jitter".
> > 
> > How do you usually fetch the bpm from Midi Clock, any pointer will be
> > welcome.
> <http://en.wikipedia.org/wiki/Phase-locked_loop>

> <http://en.wikipedia.org/wiki/Kalman_filter>

Interesting, thanks for that filter link! Could have used it before.

> MIDI clock is interesting, because deviations from the predicted clock
> frequency are either errors and must be suppressed, or are because of
> a change in tempo and must replace the old clock rate.
> Regards,
> Clemens

Hi Hermann.

Yeah, midi clock is a real pain, lots of jitter even on a 'quiet' channel,
 and gets worse on a 'busy' channel.

In MusE, I provide the user with several midi-clock-to-tempo filtering options.

My goal in MusE's case was to record a complete tempo graph for the whole 
 song, as it is playing from the external device, based on the midi clocks.

If the user expects that for a given song the external tempo will be only
 one value and never change, I provide very heavy multi-stage filtering 
 option: 4 stages each with 48-sample filters for a total of 192-sample 
 filter. Ultimately it produces a pretty flat tempo graph with only
 one, maybe two or three, tempo values - a very low data count.

If the user expects an occasional sudden 'step' in tempo, I provide
 another filter similar to the one I described, except it has a first-stage
 'large step pre-detector' to catch large steps better.

I also provide three other filters: 
Tiny: 2-stage x 4 samples = 8 samples =  1/8T note averaging.
Small: 3-stage 12/8/4 samples =24 samples = 1/4 note averaging.
Medium: 3-stage 28/12/8 samples = 48 samples = 1/2 note averaging.
And last, I provide a 'no filtering' option which records the tempos
 'as-is' with no filtering. I warn the user this may produce a very
 dense tempo graph with many small 'jittery' changes - a high data count.

Here's the thing: The tempo graph is used upon playback to govern
 the tempo of the song. If wave files are also involved in the playback,
 and midi clock was filtered, the playback synchronization of midi 
 with waves may drift due to the averaging of the filters.
So in this case, with wave files involved, I inform the user that the 
 best option here is the last one: 'no clock filtering' at all.
It produces a very dense 'verbose' tempo graph with lots of small
 jittery changes - BUT - it is the most accurate for playback and
 provides your best chance of exact synchronization - nothing was lost
 due to averaging.


More information about the Linux-audio-dev mailing list