PLN's report: "no impact of lcxl in ardour... why would i need to remap midi
controls there across lcxl gens?" He is right: he never needs to remap. The
session file has the learned bindings (v2 CC 77-84 + 13-16, channel 1) and the
lcxl3-driver emits exactly that. The path was broken in TWO places, both by
name-vs-identity rot:
1. midi-autoconnect resolved its source by NAME and connected "name:0" — but
aconnect resolves CLIENT names only, and the driver's virtual port carries
its name on the PORT line (client = python-rtmidi's 'RtMidiOut Client').
The connect failed into 2>/dev/null for exactly the source the candidate
list most prefers, so Midi Through carried NOTHING in DAW mode. Now the
resolver returns a numeric client:port address (awk over aconnect -i,
matching client AND port lines). Fourth name-identity bug of the day.
2. Ardour's Generic-MIDI input connection was saved by device identity, and
that identity was "ALSA;;C922 Pro Stream Webcam" — the webcam had taken
over the slot the surface once owned. The purest stale-binding specimen the
rig has produced. tidal-ardour-autoroute now asserts
Midi-Bridge Midi Through -> ardour:MIDI Control In on its 2 s cadence,
no-op until Ardour registers the port, permanent once it does.
Midi Through stays the rendezvous ON PURPOSE: v2 raw or v3-translated, both
feed it, which is what keeps the classic LCXL plug-and-play (the BC
constraint). Ardour 9.7 note for the archives: the Control Surfaces page is
now a vendor tree built from the .map files' manufacturer field — the old
"Generic MIDI" lives under vendor "Any" (GenericMIDI.map, manufacturer="Any"),
NOT under "Other", and Novation's "Launch Control XL (generic)" entry is the
factory map that would OVERRIDE the learned bindings — do not enable it.
