BPM not quite correct? (BPM drift) Any recommended solution? Is the third party MIDI library causing that? #61

Wondering if maybe millis() is incorrectly faster than it should be. Maybe some issue with the ESP32 Arduino library?
Saying that because of this:
'/* If MIDI is playing, then check for tick /
if (midi_playing && (now - last_midi_tick) >= midi_tick_ms) {
OMNI_do_midi_tick();
last_midi_tick += midi_tick_ms;
if (last_midi_tick < now) {
/ we are at least one tick late, give up */
last_midi_tick = now;
}
}
}'

BPM seems generally accurate at 50 BPM, 100 BPM, and 150 BPM (although didn't run it very long), and 110 BPM seems to actually be about 110.3 BPM, and 120 BPM seems to be about 121 BPM. 130 BPM seems to be about 131.6 BPM. 140 BPM seems to be about 141.5 BPM.
Surprisingly 150 BPM seems to be 150 BPM.
160 BPM seems to be about 163 BPM. 170 BPM seems to be about 170.45.

By the way, I did change this, so maybe that caused it?:
#define MIDI_TICKS_PER_16TH 2

Seems to maybe be a rounding error. Would using microseconds instead of milliseconds for midi_tick_ms solve that?

As i remember, now it is waiting for timer value to overcome 1 ms and then calls some onTick() method and resets the 1 ms counter. The right action instead would be adding 1000 us for the next triggering value, this would compensate introduced errors when it triggers not at 1000us exactly, but at 1005 or any other "greater or equal than 1000 value", so correct version would set next at 2000, not at 2005.

The code seems to be correct, except for this guard

if (last_midi_tick < now) {
/ we are at least one tick late, give up */
last_midi_tick = now;
}

But i am not sure that it is executed ever. Maybe the micros itself are faulty.. dunno

Tick coef is nothing misterious, but [microseconds in 1 second] ×ばつ [60 seconds in a minute] / [4 quarters notes in a bar] / [ticks in a 16th note]
Where 60/4 gives 15
Then later we use coef/bpm, we get micros/tick value

After about 5 hours or more, I found that 'const float tick_coef = 7477800;' is generally "close enough" (2 MIDI_TICKS_PER_16TH).
I can try 'if (midi_playing && (now - last_midi_tick) >= midi_tick_ms) {
do_midi_tick();
while (last_midi_tick < now) {
last_midi_tick += midi_tick_ms;
}
}' next.

By the way, tried adding single "flam" (adding a second drum sound by using that 2 MIDI_TICKS_PER_16TH), but it seems that was too much for the CPU to handle. I may make a more basic sample player to see if that makes it better.

Recommend any open source simple sample players (with MIDI) for playing an array of those uint_8t hexadecimal Mono 16 bit PCM samples? Guess it wouldn't be difficult to make one, but adding the MIDI part looks excessive to do if there is already a good one that is efficient.

Think there is a sample player in AudioKit, so may look at that to see if it is C or C++ under the Swift code.

For me this version works with no glitches, but I don't know how accurate it is.

void run_tick() {
 now = micros();
 button_divider++;
 if (button_divider >= 4) {
 for (int i = 0; i < ButLast; i++) {
 read_button(&buttons[i]);
 }
 run_ui();
 button_divider = 0;
 }
 // If MIDI is playing, then check for tick
 if (midi_playing && (now - last_midi_tick) >= midi_tick_ms) { 
 do_midi_tick();
 // sync in case we are late
 while (last_midi_tick < now) {
 last_midi_tick += midi_tick_ms;
 } 
 }
}

Because before this mod, in case when we are late, it forced last_midi_tick = now;, which is not mathematically correct, cause it zeroes the phase instead of wrapping it.
Note that the clause (now - last_midi_tick) >= midi_tick_ms doesn't check for the number of triggered ticks, just fires if >=, so if the CPU 's been busy, it could have missed some ticks theoretically. So this is the guard to stay in sync.
All the other code seems to be correct, so maybe internal micros counter is slightly faulty - I've never checked how accurate it is.

They say, the internal quartz is quite reliable to expect +/-3.6 seconds per hour.

By the way, tried the drum roll code again today after the BPM was adjusted to base on milliseconds and using that adjusted coef I posted before, and it thankfully sounds good now.
Sadly the bass drum sound still doesn't play occasionally, seemingly because it's a longer array.

Anyway, here is that simple flam code for inside of do_midi_tick():
//EXPERIMENTAL DOUBLE C_HAT:
if (midi_tick == 1){
instr_noteon(3,45,0,0);
}

I want to add synth shuffle also, but eliminating that random missing bass drum sound (and adding proper rolling) is higher priority.