1 Nov
2014
1 Nov
'14
7:29 p.m.
Hi
I try to fetch the bpm from the Midi Clock, and stumble over "jitter".
So I start to collect data for a larger amount of time, but it wouldn't
help.
Here is what I do:
else if ((in_event.buffer[0] ) == 0xf8) { // midi beat clock
clock_gettime(CLOCK_MONOTONIC, &ts1);
time0 = (ts1.tv_sec*1000000000.0)+(ts1.tv_nsec);
static int collect = 0;
static int bpm = 0;
bpm += ((1000000000 / (time0-time1) / 24) * 60); // nanosec
to bpm
collect+=1;
if (collect >=30) {
set_bpm_val(bpm/collect);
collect = 0;
bpm = 0;
}
timed = time0-time1;
// printf("Midi clock event %X time0 %f time1 %f timed %f
ts1.tv_nsec %lu\n",in_event.buffer[0], time0, time1, timed, ts1.tv_nsec);
time1 = time0;
} else if ((in_event.buffer[0] ) == 0xfa) { // midi clock start
printf("Midi clock start\n");
//set_ctr_val(MIDICLOCK, 1);
} else if ((in_event.buffer[0] ) == 0xfb) { // midi beat
clock continue
//set_ctr_val(MIDICLOCK, 1);
printf("Midi clock continue\n");
}else if ((in_event.buffer[0] ) == 0xfc) { // midi beat clock
stop
//set_ctr_val(MIDICLOCK, 0);
printf("Midi clock stop\n");
} else {
printf("CC number %x\n", in_event.buffer[0] );
}
tim0 and time1 are set as double.
I experience jitter around 1 or 2 beats around the "original bpm set in
the master.
When master is set to 360 I receive 374.
How do you usually fetch the bpm from Midi Clock, any pointer will be
welcome.
regards
hermann
1 Nov
1 Nov
8:10 p.m.
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>
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
9:55 p.m.
New subject: [Bulk] Re: Midi Beat Clock to BPM
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.
HTH.
Tim.
2 Nov
2 Nov
12:53 a.m.
On 11/01/2014 08:10 PM, Clemens Ladisch wrote:
hermann meyer wrote:
A very good paper with example code:
http://kokkinizita.linuxaudio.org/papers/usingdll.pdf
(ardour uses that approach to filter MTC, LTC and MClk)
ciao,
robin
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>
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.
8 Nov
8 Nov
7:04 p.m.
Am 02.11.2014 00:53, schrieb Robin Gareus:
On 11/01/2014 08:10 PM, Clemens Ladisch wrote:
Thanks for all replies,
At least I didn't look for smoothing value changes, but more for initial
correct bpm values on stable situations.
I solve my issue/mostly/ by adding the event frame time
(nsec)(1000000000.0 / (sample rate / frame_time)) to clock_gettime. This
lead to correct bpm values with max ~1bpm offset.
regards
hermann
hermann meyer wrote:
A very good paper with example code:
http://kokkinizita.linuxaudio.org/papers/usingdll.pdf
(ardour uses that approach to filter MTC, LTC and MClk)
ciao,
robin
_______________________________________________ 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>
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.
3696
days inactive
3703
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
4 participants
participants (4)
-
Clemens Ladisch -
hermann meyer -
Robin Gareus -
Tim E. Real