Two findings from one question. PLN asked whether a track change made him
press ^41 twice; it does, and carry_values() is explicit about why -- the
latch is cleared in the driver and no CC is sent, so SuperDirt keeps the old
127 while the driver believes the gate is shut. Press one re-sends 127 and
nothing moves. The driver's journal has the exact event at 00:38:41, two
latches cleared, ten seconds before love_first loaded.

The docstring's reason is the inverted part: it clears the latch 'so the LEDs
stop lying', but the gate is still open in SC after the change, so the lit
LED was the truth. Post-gig fix, because this is the mute path: carry the
latch for buttons the new track also maps, clear-and-emit-0 for the ones it
does not. Thursday's workaround is to close gates before switching, which
the journal already grades -- 0 latches cleared is a clean switch.

Verifying it from the MIDI log was impossible because there is none: 16227
sample records, 0 cc records, the tenth session running. find_seq_port
matches port names by substring, the driver publishes 'ParVagues LCXL3 ' and
'ParVagues LCXL3 FB' as a pair, and the resolver bound the FB input. Nothing
sends corpus CCs to an RtMidi input, so the reader subscribed and read
silence. The name was fixed in September; the direction never was.