A new Launch Control XL 3 sat there showing factory-default LEDs. Not autostart
(lcxl-leds-watch was active), not wiring (aconnect showed the surface connected
to Midi Through): the port resolver matches the product name "Launch Control XL",
and the mk3 enumerates as "LCXL3 1". So _find_hw_port()/_find_seq_port() both
returned None and every frame went into the void — while the parse stage kept
logging "-> 27 controls" and looking perfectly healthy. A failure with no error
message, which is the worst kind and the whole reason gig-preflight now exists.
NAME_RE also matches \blcxl\d*\b. The inline HUI exclusion becomes SKIP_PORT_RE,
which additionally drops the mk3's DAW and "To DIN" ports — the mk2 exposed one
non-LED port, the mk3 exposes three, and sending a frame to any of them is a
silent no-op.
Validated: resolver now returns hw:1,0,0 and seq 20:0; it returned None before.
NOT fixed here — the LED dialect. The device answered a Universal Device Inquiry
with:
F0 7E 00 06 02 00 20 29 48 01 00 00 01 01 0B 39 F7
Novation family firmware 1.1.11
and per Novation's programmer's reference the mk3 lights controls in RGB, one
message per control:
F0 00 20 29 02 15 01 53 <control index> <R> <G> <B> F7
versus this file's mk2 frame: device id 0x11, command 0x78, a User-1 template,
batched (index, value) pairs, and a bicolor 2-bit red x 2-bit green = 16-state
colour model. So mk3 support is a second dialect plus a replacement colour model
(RGB doesn't map onto 16 bicolor states), and the per-control message form means
a full 40-control repaint costs 40 SysEx messages where the mk2 cost one — the
paint loop will need rate limiting. Tracked in SRE TODO.d.
