Add accurate midi timestamps #477
Conversation
This allows tracking the accurate time a midi event came in, instead of waiting to timestamp in our potentially slow or laggy event loop. Also needs a non-thread-blocking led render. Needed for accurate midi file recording.
stephen322
force-pushed
the
midi_reorg
branch
from
ab4bd6e
to
b2b9656
Compare
|
Updated to use time.perf_counter(): |
| @@ -158,7 +158,7 @@ def log_unhandled_exception(exc_type, exc_value, exc_traceback): | |||
| midiports.last_activity = time.time() | |||
| hotspot.hotspot_script_time = time.time() | |||
|
|
|||
| last_control_change = 0 | |||
| last_sustain = 0 | |||
There was a problem hiding this comment.
I'm being a bit nitpicky, but is there a specific reason for changing the name of this variable? It should be keeping track of every 'control_change,' not just sustain.
| value = msg.value | ||
|
|
||
| # midi control 64 = sustain pedal | ||
| if control == 64: |
There was a problem hiding this comment.
I see now the reason for variable change, but why limit it only to a sustain pedal?
There was a problem hiding this comment.
Maybe I misread intent?
The variable is only ever checked in fade processing, and specifically against "pedal_deadzone" so I assumed that meant sustain.
Hmm, if it's any control, then what about "modulation", "volume", "expression", etc., or any number of private-use CC's?
I was thinking about tracking CC changes in "midi_state" when designing ColorMode interface, but so far nothing is using it, so it remains unimplemented...
There was a problem hiding this comment.
I see, I thought you had something else in mind. If it is currently used in only one scenario, the new name is even more fitting.
|
I manually tested light modes, recording, playing, and sequences. Everything seems to be working fine. |
Add midi timestamps via Mido callback.
I originally wrote this in July/Aug, (and re-wrote now due to the many upstream changes). But never created a pull request because it's all for naught if PixelStrip's render holds the GIL for the duration. On my Pi/ledstrip setup, it's held for a good 11ms, which means any two notes could be recorded off by up to 22ms, enough to be noticeable.
This time I decided to patch rpi-ws281x to prevent GIL locking during render:
rpi-ws281x/rpi-ws281x-python#102
This should make the project much more thread-friendly regardless of the timestamps.
There's also discussion on Mido to use the backend rtmidi's delta timestamps:
https://github.com/orgs/mido/discussions/485
But I'm not sure if those deltas would also be affected by PixelStrip's render lock.
The midi parsing in visualizer.py was also cleaned up a bit.