Three gaps PLN hit launching the rig on 2026-08-29, reported as "had to launch
ardour myself / had to open midi watch myself / once opened had to wire it to
midi through myself". All three were real, and one of them nearly got "fixed"
the wrong way.
GAP 1 — the button looked dead for over a minute. _run() ran gig-up --converge
to completion (~100 s on a cold boot while SuperDirt warms 51 banks, up to the
300 s timeout) and only THEN launched the apps. So RIG UP showed a spinner and
no window, PLN concluded it had failed, and launched Ardour by hand.
My first attempt was to launch the apps first. That was wrong, and PLN caught
it: "superdirt froze before loading midi when in my launcher, when ardour was
midi connected, had to untick ardour midi, then launch". Ardour holding the
surface makes sclang hang inside MIDIClient.init / MIDIIn.connectAll — the same
rawmidi contention that stops `amidi` writing LEDs while SC is up. The original
ordering was not an accident, it was load-bearing, and reordering it would have
traded a cosmetic complaint for a reliable boot freeze. Reverted.
The correct shape is a SPLIT, not a reorder:
PRE_APPS = ["pulsar"] touch no MIDI -> open immediately
POST_APPS = ["ardour", "midimon"] contend for the surface -> wait
Pulsar's GHCi reaches Tidal over TCP 6010 and never touches ALSA, so it can
open at once and give the button a visible effect within a second, while its own
multi-second startup overlaps converge instead of queuing behind it. Ardour
still waits for SuperDirt to own MIDI first. Converge output now appends to the
launch lines rather than overwriting them, so the log shows both halves.
GAP 2 — midimon was in NEITHER list. RIG UP never had it to open, so "had to
open midi watch myself" was exactly correct. Added to POST_APPS.
GAP 3 — midimon opened blind. `aseqdump` with no -p subscribes to nothing and
prints "Waiting for data at port", so every launch needed hand-wiring before it
could be used. Added resolve_port(), which picks the most interesting source
present, in a deliberate order: the lcxl3-driver's TRANSLATED stream first
(the numbers the corpus speaks — what you want when a knob does the wrong
thing), then the raw v3 DAW port (the numbers the hardware speaks — for "is it
even sending"), then the custom-mode port, then Midi Through as a catch-all.
It matches CLIENT and PORT names both, because python-rtmidi registers the
driver's client as 'RtMidiOut Client' and puts 'ParVagues LCXL3' on the port —
a client-only match misses precisely the stream most worth watching. That is
the third bug today caused by treating a MIDI endpoint's name as its identity.
Verified with the driver running: resolve_port() -> ('133:0', 'ParVagues LCXL3'),
i.e. it selects the translated stream over the two raw ports and Midi Through.
