-
gig-log: the MIDI leg had never once bound a port · f67cf28e
find_seq_port defaulted to the literal string 'Launch Control XL' — the ORIGINAL board's product name. The LCXL3 advertises itself as 'LCXL3 1', so the resolver matched nothing from the day the hardware changed. All nine recorded sessions from 2026-09-06 onward contain zero cc records, and every one of their headers says "midi": true, because available() only asks whether aseqdump is installed: the reader existed, reported itself on, and bound nothing. run() re-resolved every 5s exactly as designed, forever, against a name that could not match. Now it walks the same authored preference midimon and midiviz use, translated port first, because corpus numbering is the only numbering a log is worth mining in. A night that falls through to the board's own DAW port is translated through lcxl_grid.V3_TO_V2 on the way into the window, so the log is always in corpus numbers and a reader months later never has to know which port that night happened to bind — and an 'mbind' record now states the port, the name and whether translation was applied, since the nine silent sessions happened precisely because nothing recorded that the answer was none. Coalescing is unchanged and keeps v0/v1/lo/hi/n, which is what makes 'minute 23:30 the bass is too saturated' answerable from the file. Also adds tools/check-stale-units.py: a unit running three-day-old code is indistinguishable from a healthy one from outside, and comparing its start time to its ExecStart file's mtime is the only honest test.
PLN (Algolia) authoredf67cf28e
×