during release testing, i realized that after my ~40th script load, clock.sync calls were off by a tenth of a beat, compounding as i continued to load scripts.
i started rolling back through commits and when i verified that b932b0d sparked the issue's emergence, i realized that the send_midi_clock table was being added to each time clock.add_params() was called, but never emptied out. so, eventually, the clock was doing 24ppqn calls on a table with tons of entries.
i guess nice to accidentally stress-test that a lot of devices could receive MIDI clock before timing issues emerged? anyway, fixed now!
during release testing, i realized that after my ~40th script load,
clock.synccalls were off by a tenth of a beat, compounding as i continued to load scripts.i started rolling back through commits and when i verified that b932b0d sparked the issue's emergence, i realized that the
send_midi_clocktable was being added to each timeclock.add_params()was called, but never emptied out. so, eventually, the clock was doing 24ppqn calls on a table with tons of entries.i guess nice to accidentally stress-test that a lot of devices could receive MIDI clock before timing issues emerged? anyway, fixed now!