fix(midi): cut the surface's direct leg to SuperCollider, every 2s
SuperDirt's boot runs MIDIIn.connectAll (start_and_midi.scd:19), so SC subscribes to every hardware MIDI input it can see -- the LCXL included. The surface then fed SC twice: once raw, once through Midi Through. And MIDIFunc.cc takes `src` and never checks it (start_and_midi.scd:51), so every CC fired the handler twice and every button noteOn double-fired into ~lcxlChordCheck. A double noteOn on a toggle is a no-op: that is how a mute button silently stops working. lcxl3-driver's prune() handled this for the v3 board, but only while it runs -- and it was stopped today (stale binding to an unplugged mk3, Conflicts=-killing the mk1 painter). A hand-run `aconnect -d` fixed it live and then SC restarted and re-armed it, which is the whole argument for putting it in the reconcile loop that already owns the wiring. Rule 3 matches the RAW board on type=kernel, never on name alone: lcxl3-driver publishes a virtual port called 'ParVagues LCXL3' that matches the same name candidates, and cutting the driver's translated feed would kill the path we actually want. Only surface->SuperCollider links are cut; -> Midi Through and the aseqdump taps that gig-log and the Pulsar HUD read all survive, verified live. Tested by arming the bug (aconnect 20:0 130:3, 20:1 130:4) and watching the loop cut both and settle: lcxl-path.py went from "LCXL -> SC direct" back to "LCXL -> Midi Through -> SC", logged once, no per-tick spam, and gig-log kept counting touched controls. Also logs PLN's ear-feedback on the classic-LCXL play-test (rose_rouge works great; midiviz landed) to the archivist's notes.
Showing
Please
register
or
sign in
to comment