Three rounds of screen fixes were hypotheses dressed as patches: the lap clock
is frozen at 0:00 on glass while our ghost ticks, and the DJF Hz readout
"refresh maybe every 1s, not smooth at all". Both point at one unproven rule —
that a field write to an ALREADY-VISIBLE display target does not repaint
without a bring-up — and the protocol offers no display readback, so the only
instrument that can settle it is PLN's eyes, asked precise questions in order.

So: a guided probe. Each step prints an instruction, sends a minimal
distinguishing sequence, and records what he saw; the run ends with a table and
a verdict naming the surviving hypothesis, plus JSON in the scratchpad so the
answers outlive the session. --dry-run prints every byte with the hypothesis it
tests, so the whole thing is reviewable without hardware.

It distinguishes: bring-up NONE/AFTER/BEFORE/RECONFIG on the stationary target;
the same on the temporary target plus a 20/10/5-per-second rate ladder (which
directly decides the DJF smoothness fix); whether per-control targets can be
driven while untouched; which auto bit actually summons; and an arrangement
census with a SENTINEL, so an arrangement the firmware IGNORES reads as "still
the sentinel" instead of masquerading as a real layout — without that, "ignored"
and "renders like the previous one" are the same observation and the census
would invent arrangements that do not exist.

Two things it found by reading our code, before touching the device. The
targets showing both symptoms are on arrangement 2, not the 4 we describe in
our own notes (4 is only label_control's default). And CFG_BRING_UP = 0x7F is
arithmetically ARR_TRIGGER | AUTO_TOUCH | AUTO_CHANGE, so every bring-up may
RE-ARM the auto-display bits we deliberately clear on the three DJF knobs —
which would explain, mechanically, why the firmware's number keeps reappearing
over "HPF 3.4kHz !!". That became its own probe step.

Safety, since the rig is live: display and config SysEx only, enforced by an AST
check that there are zero cc/note/rgb/feature call sites plus raisers installed
over those methods at open time; it refuses to run while the driver is up
(printing the pid, the kill, and the restart line); and it restores the
arrangement the driver expects from a finally block.

NOT YET RUN ON HARDWARE — committed so the work is not parked in a scratchpad.

PLN: "ok lets list my demands not handled yet and ensure we track all tasks and
ergonomic issues to improve". So the register: every open ask with his own words
attached, stable IDs, grouped by what unblocks what — and the honest note that
ONE probe run at the desk unblocks five screen items at once.

The fix came out of writing it. nouvelle_couleur.tidal carries a parked tempo
knob, a commented `# cps ((range 60 180 "^29")/60/4)`, and the mapped-set
scanner read commented lines — so B1 glowed on a board whose oldest rule is
"dark = unmapped". parse_context already skipped comments; parse_track now does
too. Live: 12 controls -> 11, 18 lit cells -> 17, B1 dark. Uncomment the line
and the next follow tick (under a second) lights it and the tempo readout
appears with it.

Also recorded: the v2 lcxl-leds-watch service has been logging "no LCXL
sequencer port" every 30 s since 22:39 — its name regex cannot match "LCXL3 1",
so it has never touched the v3 board. It was my prime suspect for the
paint-reset mystery and it is innocent; that mystery is reopened with no
suspect. The Midi-Through to SuperCollider re-add is explained though:
MIDIIn.connectAll, re-running on sample reload, exactly as
midi-autoconnect.sh's own header warned it would.

The driver parsed its .tidal once, at launch, and never looked again. PLN said
it three ways in one session: "i see still ROSE_ROUGE in title", "why dont i
see the lcxl colors evolve as i map buttons on the new track", "probably this
will be an opp to confirm you read current file well". One bug, three faces.

FOLLOW. The editor has published the loaded track for a while
(~/.cache/parvagues/current-track, written by the HUD) and logs every
ctrl+enter (eval-events.jsonl). The driver needed no new channel — it needed to
read. It now polls both once a second: a different path is a track change
(remap, relabel all 32 targets, repaint, reset the lap clock), and a changed
mtime on the SAME path is a re-read, so mapping a button and saving lights the
board within a second. --no-follow pins the old behaviour.

CARRY POLICY, PLN's spec verbatim: "faders are real positions, but could we
reset the knobs to 'defaults' on all effects? and maybe teh DJFs stay across
tracks so i can do djf-and-fader-crossfaded-transitions". So DJFs carry (they
ARE the transition), effect knobs go to 0, faders are physical and untouched.
Two cells carry that he did not name, because the sound would have taught us
the hard way: the TEMPO knob (resetting it means the range floor — a 60->120
transition would slam back to 60 exactly when the new track lands) and every
button (emitting to a gate is the mutebomb; latches reset in the driver so the
LEDs stop lying, but nothing is sent).

LIVE TEMPO. sept1's idiom `# cps ((range 60 180 "^29")/60/4)` makes B1 the
clock — and it steered the tempo all last session while the OLED said "B1
unmapped", which is the whole argument for following the track: the sound was
right and every label lied. The BPM is now derived from the knob, and bar phase
is INTEGRATED rather than read off the wall clock, because `time.time() * bpm /
60` re-scales all of history whenever the tempo moves — the countdown would
have jumped precisely mid-transition, the one moment it is read.

THE MOVE. PLN: "start holding kick mute, move kick to the 120bpm position (i
used the center notch, now ill rely on OLED), drop kick mute at end of a bar".
So the screen becomes the notch: BPM not wire units, an arrow to the nearest
landmark that vanishes when he is on it, and — while a mute is held — the bar
countdown ("DROP kick / ~120 BPM >2"), with the ring breathing at the beat to
count it in. The bar is real, not guessed: `resetCycles` shares a block with
the patterns, so every ctrl+enter IS cycle 0 and the eval log is a phase anchor.

Plus software detents, since the v3 encoder has no ridge: a deliberate single
click that would cross a musical tempo lands ON it and holds for two more
clicks; fast sweeps pass through untouched. Two versions of that welded the
knob to the first notch it met (the closest STEP to a landmark sits just below
it, so stepping up re-crossed it and snapped back — measured, 24 consecutive
clicks stuck at 114.8 BPM); the fix tracks WHICH landmark holds us by identity
and releases only once the value has actually left it.

And the mute overlay finally reports the whole held SET ("MUTE x2 /
kick+percs", "all") instead of the last finger down.

Honesty notes: 60-180 over 128 steps is 0.94 BPM/step, so exactly 120 is not
reachable (step 63 -> 119.5, step 64 -> 120.4). The readout prints "~120" for
the closest step and a bare "120" only when it is exact. A track wanting true
round tempos can quantise in the pattern:
`# cps ((quantise 1 (range 60 180 "^29"))/60/4)` — then two steps both land on
120 and the detent is the music's, not the driver's.

Also closed by evidence rather than code: A1's label is correct ("d9 level
[ard]" — the grid puts d9-d12 on row A, faders carry d1-d8), so the suspected
off-by-one that sat on the board was never real.

Ground-truth pass found lcxl-leds-watch.service (the v2 LED watcher) still
running beside the v3 driver — the likely author of the paint-reset mystery —
and midi-autoconnect as the probable Midi-Thru→SC re-adder. Plan: kill the
tug-of-war first, then the A1 label off-by-one, then the generalize thread
PLN named (track-follow + live BPM from the cps knob), then the display
probe with his eyes on the device.

sept1.tidal proved the architecture mid-set: translation is track-agnostic
(the cps knob on ^29 changed tempo with the driver still mapped for
rose_rouge), so playability generalizes for free and only paint/labels/BPM
are per-track — exactly the next thread. Fresh eye-batch bugs boarded with
the discipline note: READ label_control before believing the off-by-one.

The Pinterest bloom gif is one-way (bud → full rose on black), so a
plain loop snaps. Four loop treatments now sit in visuals/scenes/,
auditionable live by swapping the header directive (ctrl+s reapplies):

  rose_bloom          ping-pong at half speed, mci-interpolated —
                      the rose breathes open/closed over ~13.5s (default twin)
  rose_bloom_fast     ping-pong at native speed (~6.8s cycle)
  rose_bloom_rebloom  seam-crossfade: blooms again every ~2.5s
  rose_bloom_noir     fade through black, cinematic gap

Recipes (ffmpeg): ping-pong = split+reverse+concat with boundary frames
trimmed; slow = setpts 2x + minterpolate mci; rebloom = xfade against
itself, trim [fade, offset+fade]; seams verified by first/last-frame
RMSE (0.028 = codec noise for the ping-pongs).

Source renamed to ~/Downloads/rose_bloom.gif (stable stem for the
twin lookup).

Two things, one restart.

The 10-second home-refresh ticker read last_home, which was never initialised:
my init patch targeted the pre-merge line and the merged code had renamed it
(last_labels joined the chain), so the replace silently no-opped — I had
asserted every replacement in that patch EXCEPT this one. The driver died at
its first tick, 10 s after start, while the surface kept showing the labels
the startup had already written: a dead translator behind a live-looking
display. Fixed, and verified past the tick this time.

And the stuck "0" PLN saw on row 3: arrangement 4's numeric value is drawn by
the FIRMWARE from its own internal control value, which never moves for a
relative encoder — the driver owns those values now. So the driver echoes each
integrated value back to the device on the encoder's own CC (plain DAW-style
feedback). --no-echo exists in case the echo ever fights the RGB paint; the
2 s paint reassert heals any skirmish regardless.

Next display experiment, deliberately not built blind: arrangement 1
(host-supplied TEXT value) on per-control targets, which would let
probability-style constructs (sometimesBy / someCyclesBy / midiOn ranges)
read as percentages instead of 0-127.

PLN, from the chair: seated, OLED row 2 reads clearly and row 3 hides behind
the bezel. So the information hierarchy now follows the sightline, not the
protocol's field order:

- HOME: track name / "118BPM 4:32" / ParVagues. The drip moves to the bezel
  row; tempo and TIME PLAYED take the prime row. The elapsed counter is the
  overstretch check PLN asked for ("maybe time played that track eventually
  when in a set recording to help know when overstretching") — refreshed every
  10 s by a field write on the stationary target, no re-summon. Lap reset
  belongs to the future Track </> setlist cursor; today, track load = lap 0.
- DJF overlay: "DJF percs" / "LPF 2.4kHz !!" / (blank). The cell name is gone
  entirely — "C1 C2 C3 are noise i know the button positions ahah".
- Gates: "d1 gate" / "ON" / context. Value rides row 2 everywhere.
- The zero-mark heart animation moved to row 2 with everything else.

Display byte-pinning tests still pass; the ghost mirrors the new layout.

Pre-compact ritual: 11 threads closed tonight, 8 resume points with exact
next commands. The theme of the night was identity bugs — a port's name is
not the port, a device's saved identity is not the device — written up in
log 036 and banked to memory (ardour9 generic midi, worktree roots,
34-display-targets protocol update).

The LCXL3 OLED fix as a story: three rounds tuning a keep-alive for a race that
was unwinnable by construction, and the partial symptom (buttons were always
fine) that pointed at addressing rather than timing the whole time.

PLN, three rounds in: the OLED "still shows values". Move a fader and you get
the firmware's bare 0-127; move a relative encoder and you get "0", because the
wire value of a relative encoder IS 0-ish. "No info at all." Meanwhile our own
overlay — track name, what the control does, a readout — was being re-summoned
every 0.9 s under a 1.2 s firmware timeout, field-diffed, stamped only on real
bring-ups. Three increasingly clever versions of the same losing move.

The programmer's reference says why, in the display chapter's first list:

    "• 05h (5) - 24h (36): Temporary display for Analogue controls (same as CC
       indices, 05h (5) - 0Ch (12): Faders, 0Dh (13) - 24h (36): Encoders)
     • 35h (53): Permanent/Stationary display
     • 36h (54): Overlay/Temporary display"

There are not two display targets. There are thirty-four. Every fader and every
encoder owns a display target of its own, addressed by its own DAW-mode CC
index, and THAT is the one the firmware auto-triggers when you touch the
control — not 36h, which is where we had been writing all evening. Config bit 6
is its on-switch and it defaults to on:

    "• Bit 6: Allow Launch Control XL 3 to generate temporary display
       automatically on Change (default: Set).
     • Bit 5: Allow Launch Control XL 3 to generate temporary display
       automatically on Touch (default: Set; this is the Shift + rotate)."

So a fader sweep fired target 05h thirty times a second while we re-summoned
36h once a second. Unwinnable by construction, and no amount of keep-alive
tuning was ever going to change that. It also explains the one part of the
symptom that never fit a timeout story — buttons were fine. Buttons live at
25h-34h, outside the analogue range, own no per-control target, and so were
never contested at all.

And the fix is not to win the fight. Arrangement 4 is the firmware's default:

    "4 | 2 lines: Parameter Name and Numeric Parameter Value (default) | Yes | 1 | Name"

One field, Name, and a value the firmware draws itself. The Name field was
empty because nobody had ever written it. Write it, and the display we were
trying to suppress becomes the display we wanted: it already tracks the value at
wire speed and already times its own dismissal. So the driver now labels all 32
analogue controls on their own targets at startup — "d4 # crushbus",
"d5 # octerbus", "d1 level [ard]" — and stands down from the overlay for them.

Faders and A1-A4 carry no ^NN in any .tidal, because they are Ardour-learned
levels; their label comes from the grid's role table instead, with an explicit
[ard] mark. Mid-set, "this fader is Ardour's, not Tidal's" is the most useful
sixteen characters the panel can hold. Unmapped controls say "unmapped", because
dark-means-unmapped is the surface's oldest rule and the screen must not
contradict the LED beside it.

Three controls keep our overlay: the DJF knobs. "HPF 3.4kHz !!" and the heart
frames at the zero detent are prose, and arrangement 4's value field is a
number. For exactly those three targets we clear bits 5+6 — which is the
documented, per-control way to make the firmware stand down — and take the
screen back uncontested. Restored on exit, since a next session finding three
knobs that silently refuse to show a value would be a worse bug than this one.

Along the way, three things the per-control screen made visible by being the
first thing to render our labels at full width:

- set_text filtered to `0x20 <= c <= 0x7E` and so dropped the four reassigned
  control codes its own docstring advertised. The language module's heart frames
  had been arriving as plain spaces this whole time.
- parse_context said "an inline trailing comment IS the best label" and did not
  do it: the only `--` strip was anchored at the start of the body, where a
  trailing comment never is, so the Haskell always won. C8 of piment_bresilien
  read `d8 # n "23")) --` on a line ending in PLN's own `-- Raise COMEON!`.
  The comment is split off first now and preferred.
- With no stage note, the body fallback was raw combinator soup. It now reads
  the sample name off the first quoted string and the effect off the first
  identifier — "break:18", "n 6" — which is what PLN asked the line to say
  ("sample name or effect like 'rose:4'"). Across live/: 158 syntax-noisy
  labels out of 22368 became 3.

Verification I can actually do, given a write-only display and no readback:
--show-oled dry-runs the whole label table offline, opening no port, and fails
on any name over 16 characters; the new test pins the target numbers against the
guide's table, the exact configure/set_text bytes, that a button raises instead
of writing into the void, that the hearts survive the filter, and the three
parse_context cases above. What no test can prove is a pixel. That needs eyes.

Fallbacks kept in case the name field turns out not to render: --oled-overlay
suppresses every native display and restores the uncontested-overlay behaviour
across the whole surface, and --oled-native-all hands even the DJFs to the
firmware, for the eye test that compares the two side by side.

Round 4 of the live design session, plus the nine-press census.

DJF readout speaks Hz, not percent — and the numbers come from BootTidal's own
gDJF ranges (lpf: range 180 20000 over 2v; hpf: range 20 8000 over 2(v-.5)),
so what the OLED says is what the filter DOES. The zero mark animates: heart
frames at ~3 fps while a DJF rests in the detent (charset 0x1E is a heart).
Home screen line 3 is now "118 BPM" — "36 live" was a control count nobody
asked for, and PLN rightly mocked it.

The OLED GHOST (/tmp/lcxl3-oled-ghost.txt): the protocol has no display
readback, so nothing can pull the screen — instead the driver mirrors every
frame IT sends into a box-drawing the shell can read. What the ghost cannot
show is the firmware's own native value overlay, and that is the point: when
PLN's eyes see content the ghost does not have, the discrepancy itself is the
diagnosis. (That discrepancy is live: the native overlay still outdraws our
temporary text on every control move — an Opus worker is in the programmer's
reference hunting per-control display targets, the likely correct fix.)

Keep-alive: the round-3 overlay stamped _oled_up_at on every push, so after
the firmware's 1.2 s timeout our overlay was never re-summoned — one good
overlay per touch, then raw values forever. Now the bring-up re-fires every
0.9 s of continuous activity and stamps only when actually sent.

THE EDGE-BUTTON CENSUS (PLN pressed, the log answered): Solo/Arm is ONE key
(ch1 CC65, two press cycles for his presses 1+2), Mute/Select is ONE key
(CC66), the Novation logo is alive (CC104), Track </> are CC103/102, Page
up/down CC106/107. Authored as EDGE_BUTTONS in lcxl3.py; the driver now names
them in the log instead of counting them unmapped. No functions assigned yet —
the settled direction is Track = setlist cursor, Page = OLED pages, the two
verb keys = record-arm and panic, logo in reserve.

The glitch loop cut live from the Afia ad (afia_flow.gif) is now this
track's backdrop, through the HUD's new standard: the header names the
source, scene-ingest derives the playable twin into visuals/scenes/.

PLN, 2026-08-29: "midiwatch still naively verbose [`14:0 Control change ch0,
controller 29, value 15`] improve it massively. no more console, tiny borderless
window that exits on q/exit/ctrl+c/alt+f4, that renders the stream in a nicer,
cyberpunk matrix dense cryptic purple-on-dark, style. no word like 'control
change' pure viz"

The complaint is not about verbosity, it is about REGISTER. One line per event is
the right shape for a debugger and the wrong shape for a performer: a fader sweep
emits ~400 events a second, so midimon's prose scrolls past faster than an eye
can land on it, and the one question you actually have mid-set — "which orbit did
I just touch" — is the one thing a sentence makes you decode. So this is a lens,
not a log.

The picture
-----------
Zero English words render. An event's identity is its POSITION, its type is a
GLYPH CLASS, its value is a BAR plus two hex digits, and its recency is
BRIGHTNESS. The layout is the authored surface itself — lcxl_grid's rows A..F in
PHYSICAL_ORDER down, columns 1..8 across, column N *is* orbit N — so the answer
is spatial and needs no decoding. A per-orbit charge glow behind each column says
"this one is live"; the column digit brightens with it. Buttons render as latches
(filled above half, hollow below) because rows E/F are gates, not levels — a bar
would have lied about what they do. Channel shifts the hue of the digits, not of
the cell, so the cell keeps meaning "which control" while the tint carries "from
where". Only what the grid CANNOT place — foreign CCs, notes, bend, program —
falls as rain in the right-hand gutter, which makes "that came from somewhere
else" a visible fact rather than a thing you read. A ribbon along the bottom
scrolls the raw order of arrival, brightest at the right.

Every hue stays inside the violet→magenta arc, so eight roles stay
distinguishable while the window still reads as one colour.

Choices worth keeping
---------------------
* **Mapped-but-idle must not be black.** All 48 grid cells carry a floor tint
  even when nothing has ever arrived on them. "Dark = not mapped" is the reading
  a cockpit trains you into, and a dark cell that IS mapped reads as a hardware
  fault — the same trap the LED work settled.
* **Toolkit: PySide6 (Qt6), already installed (6.11.2).** PyQt6 and pygame are
  not present; GTK4 + pycairo are, but Qt gave frameless + always-on-top hints +
  startSystemMove (the only way a Wayland client may reposition itself) without
  hand-rolling a drag.
* **Two frame rates, not a busy loop.** This machine performs live audio. ~25 fps
  while events arrive, dropping to 5 fps two seconds after the last one, where
  the only motion is a slow dim pulse. Colours are a precomputed LUT (8 families
  x 16 decay levels), paint uses the int overloads, the CRT scanline texture is
  one cached pixmap blitted once, and the ribbon is bounded to exactly what fits
  so a frame copies nothing.
* **Profiled rather than guessed.** The first version cost 30.6% of a core under
  a sustained 400 ev/s sweep. Stage-by-stage timing put the cost in the sheer
  NUMBER of drawText calls, not in pixels: gutter rain alone was 3.1 ms of an
  8.9 ms frame (a 96-drop cap with a trail glyph each = up to 192 calls). Capping
  rain at 32 heads with a trail only on the brightest, batching the ribbon into
  same-colour RUNS, and 33→40 ms took the frame to 5.5 ms and the sweep to 17.7%.
  Idle is 1.4%. The ribbon batches only hex glyphs, because those are guaranteed
  to come from the monospaced face at exactly one advance — a class glyph (◆ ≈ ≡)
  may be served by a fallback face and would drift the ribbon off its grid.

Port choice: delegated, not re-derived
--------------------------------------
`midimon.resolve_port()` owns "which port", and midiviz delegates to it. Two
things about it are load-bearing and were nearly re-derived wrong here: the
preference order is authored, and it matches the whole `aseqdump -l` ROW rather
than the CLIENT column — python-rtmidi registers the lcxl3 driver's client as
'RtMidiOut Client' and puts 'ParVagues LCXL3' on the PORT. A client-name match
(which is what surface.resolve_port does, correctly, for its own purpose) falls
straight through to the raw hardware: the monitor would work and show the wrong
stream. Confirmed live on this rig, which has both up — the driver is 133:0 under
'RtMidiOut Client'. The local fallback copy exists only for trees whose midimon
predates the helper, and a test asserts it cannot drift from the original.

Launcher
--------
The `midimon` KEY is kept, so the Bridge hub's and the tray's existing button open
the new thing with no change on either face; midimon.py is untouched and remains
the terminal fallback. `terminal: True` is dropped — midiviz draws its own
window, and wrapping a GUI in konsole would have parked an empty black terminal
behind it for the length of the set. That also re-enables the already-running
guard, so the button is now idempotent instead of spawning a window per click.

Verified
--------
* `ast.parse` clean; full bridge suite 90 passed (was 78 + 12 new).
* `midiviz.py --selftest`: 3 s of synthetic events — every one of the 48 authored
  grid cells, four channels, un-gridded CCs, notes, bend, program, aftertouch,
  sysex — pushed through the REAL parse_line + enrich + ingest + paint path, 140
  paints, 68 grabs, 139 distinct sampled colours. It grabs the widget each tick,
  so the drawing code is exercised for real and offscreen, not merely constructed.
* Exit paths run, not assumed: SIGINT and SIGTERM each exit 0 from a live process
  (q/Esc/close share that path).
* Plumbing, not just pure functions: a real Reader subscribed to the resolved
  driver port with no error, and a second one pinned to Midi Through received 8
  genuine events played in with aplaymidi — aseqdump → parse_line → enrich →
  drain, end to end against real ALSA.
* Rendered and looked at, at 420x260 and at 2x, before and after the
  optimizations: identical output, which is the point of the run-length batching.

Found on the way: data-less realtime messages (Start/Stop/Continue/Clock) print
with no data column, and midimon's row regex requires one, so they never parse —
midimon's console silently omits transport too, and midiviz has four glyphs that
cannot light up. Left in midimon (one parser per concept) and pinned by a test
that says what to delete when it is fixed.

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.

surface that breathes at the track's tempo

The design session with PLN, hands on the device, four AskUserQuestion answers
and three live iterations. Everything here is v3-only BY CONSTRUCTION: the
corpus, BootTidal, SC and Ardour still speak v2 absolutes, so the classic LCXL
(PLN's fallback, and his friend's surface) keeps working with zero changes —
"we need to be BC always" is the standing constraint.

THE LANGUAGE (lcxl3_language.py, new — parallel to lcxl-leds.py, replacing
nothing):
- rings: hue = ROLE (per-orbit family anchors, warm rhythm bloc / purple bass /
  cool melodics), lightness = VALUE. This is the exact trade v2 could not make
  with three LED hues — the settled 2026-07-29 language spent all hue on value
  because role had nowhere else to live. RGB dissolves the trade.
- dark = unmapped survives unchanged: it outranks everything on both surfaces.
- DJF row C, PLN's spec after the first blue<->green attempt proved "too
  subtle": blue = lows kept, DEEP GREEN BREATHING SLOWLY = the zero mark
  (there is no pot ridge on an endless encoder — the 0 must be VISIBLE),
  then green -> yellow -> red as the HPF cut grows. Near-silence extremes
  breathe to the BEAT — sine, not blink ("a bit aggressive atm"), rate from
  the track's setcps (118 BPM for rose_rouge). Wall-clock phase: it breathes
  AT tempo without claiming to know Tidal's cycle position — true phase sync
  is a feed from SC, later, not a silent assumption now.

DRIVER-OWNED TRUTH (three kinds, one principle):
- encoder VALUES: rows B/C relative, offset-64 decode — MEASURED off PLN's
  slow clicks arriving as 63/65/66; the first decoder assumed two's complement
  and read +1 as -63, direction inverted, every click a full-range jump. Row A
  stays absolute deliberately: A1-A4 are Ardour-learned levels, and integrating
  them from a blind seed would yank a live fader toward silence.
- row-E LATCHES: the latch never lived in Tidal (midiOn/midiOff read the last
  value) — it lived in the v2 hardware's toggle buttons. v3 DAW buttons are
  momentary, so the driver flips state on press, swallows the release, and the
  LED paints driver state — which IS what Tidal hears. Row F stays momentary:
  gestures are held, and the panic chord needs four simultaneous 127s.
- PAINT as a binding: the device repaints its own defaults on events we cannot
  see, so the driver re-asserts the full board every 2 s — same doctrine as
  every aconnect link on this rig. Faders are OUT of the paint path: they have
  no LEDs, and painting them was a no-op lie this commit stops telling.

OLED:
- touched-control context in CORPUS terms, line 2 parsed from the .tidal:
  "# crushbus", "mask <f f f t>", and — best of all — PLN's own inline stage
  notes: ^35 shows "HANDS IN THE AIR", ^59 "Le Delay rose!!!", ^36 "Savoy 8/8
  Break". His words, on his hardware, at the moment his finger lands.
- anti-blink: fields are diffed and the configure/bring-up pair fires only when
  the overlay has likely expired — re-summoning a live overlay every event was
  the blink PLN saw.
- gates read ON/off, DJFs read "LPF 43% / BYPASS / HPF 61% !!".

Validated on the live rig across three rounds of PLN's eyes and hands:
translation + paint + OLED coexist in one process; 27 live cells / 13 dark on
rose_rouge; 18/18 controls context-labelled; latch verified against E1.

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.

Follow-up to fa22bb85, which fixed the direction trap but still could not run.
Two more defects, then the first verified end-to-end translation.

DEFECT 3 — the virtual port could never be found. _clients() returned
(port_id, CLIENT_name) and every lookup matched the client name. python-rtmidi
registers the client as 'RtMidiOut Client' and puts OUR chosen name on the
PORT:

    client 133: 'RtMidiOut Client' [type=user,pid=...]
        0 'ParVagues LCXL3 '

So `VIRTUAL_PORT_NAME in client_name` was false forever. The driver printed
"reconcile: src=None dst=130:0 — nothing to do yet" on every cycle while
`aconnect -i` listed the port plainly two lines below. _clients() now returns
(port_id, client_name, port_name) and _find_port() matches either — both names
are real and each is load-bearing somewhere.

DEFECT 4 — prune() would have cut the driver's own link. It skipped "our" port
by testing VIRTUAL_PORT_NAME against the name from `aconnect -l`, which is the
CLIENT name — 'RtMidiOut Client'. That never matches, so the very first prune
after a successful connect would have severed the connection it had just made,
every cycle, forever. prune() now takes an explicit set of protected PORT IDS.
Identity here is the ALSA port id; the names are decoration. Any place that
matches a MIDI endpoint by name on this rig is a latent version of this bug.

Also: reconcile() prunes only AFTER a confirmed connect. Cutting the raw
surface while the replacement stream is not actually delivering would leave a
dead surface, which is worse than a wrong one.

VERIFIED END TO END on the live rig, PLN's hands on the hardware:

    fader 1      v3 #5   -> v2 #77   (38 events, full sweep 37..0)
    button E1    v3 #37  -> v2 #41   (127 then 0)

^77 is lcxl_grid's row D cell 1 and ^41 is the kick gate — the exact control
the #94 migration aligned all 169 tracks onto, and the one v3 renumbering would
have moved to button E5. 0 unmapped, 0 dropped. The graph after prune:

    133:0  RtMidiOut Client  -> 130:0    (ours, the only surface path)
    20:0 / 20:1 LCXL3 1                  GONE from SuperCollider
    14:0 Midi Through -> 130:2           re-cut every cycle

Open, and deliberately not guessed at: something re-adds Midi Through -> SC
within 5 s. midi-autoconnect only ever creates the OTHER direction, so the
re-adder is unidentified. prune contains it each cycle; the window is real but
small, and naming a culprit without evidence is how the last three "rig is
broken" findings turned out to be the measuring tool.

Resume point 1 is closed: the driver has met a live SuperCollider, and it took
four defects to get one fader through. Every one of them was invisible to
reading — three reported success while doing nothing.

Resume point 1 was "run lcxl3-driver against a live SuperCollider, because it
never has been". It has now, and the run found two defects that no amount of
reading could have found — both invisible precisely because the code reported
success.

DEFECT 1 — the aconnect direction trap. reconcile() resolved its destination
with `_clients("-i")`:

    dst = next((p for p, n in _clients("-i") if "SuperCollider" in n), None)

`aconnect -i` lists ports you can read FROM. SuperCollider appears in both
directions: in0..in4 are destinations, out0..out6 are sources. So `-i` returned
SC's *output* port — 130:5 on this rig — and the driver ran

    aconnect ParVagues LCXL3:0  130:5

which writes into an output-only port and fails. The CompletedProcess was
discarded, so the failure had no way to be seen, and the next line printed
"reconcile: src -> dst" as though the link existed. Every previous reasoning
step about this driver rested on a connection that was never made.

Fixed by resolving destinations from `-o` via a new _sc_input_ports(), and by
checking the return code and PRINTING the failure. A reconciler that cannot say
"I failed" is decoration — the rig has been bitten by this shape before
(feedback_verify_the_plumbing, reference_check_the_instrument_first).

DEFECT 2 — reconcile only ever ADDED links, so it could not be correct here.
`MIDIIn.connectAll` subscribes SC to every source present at boot. Measured on
the live rig:

    14:0  Midi Through  -> 130:2
    20:0  LCXL3 1 MIDI  -> 130:3
    20:1  LCXL3 1 DAW   -> 130:4

So the moment the driver published a correct, translated stream, SC was hearing
it ALONGSIDE two raw ones. This is worse than duplication: v3's DAW map
collides with the corpus's v2 numbers on 16 indices with different meanings, so
row C knob 4 would drive ^52 (right) and ^32 (row B's cell) at once — two
orbits moving when one knob turns. And a doubled CC is fatal on a latch: the
toggle fires twice and cancels, which reads from the stage as "the button does
nothing".

Added prune(), which cuts every path into SC that is not our virtual port,
re-asserted on the same timer as the connect (the binding must be re-asserted,
never assumed — feedback_stale_binding_pattern). Midi Through is cut by default
because midi-autoconnect's rule 1 pushes the surface into it, i.e. it is a
second copy of the same stream; --keep-thru opts out.

Added `--graph`, which prints what actually feeds SC and what prune would do.
That is the diagnostic whose absence let defect 1 hide: the driver's own view
of the graph was never printable, so it could never be checked against reality.

Verified on the live rig (sclang 845344 / scsynth 845718, LCXL3 on client 20):
--graph now resolves 130:0-130:4 and correctly classifies 3 WOULD CUT paths and
PipeWire-RT-Event's monitor bridge as left alone. Hardware also confirms the
translation table's row D: PLN reports fader 1 = CC5, which is V3_ROWS["D"][0].

Eleven threads closed, six resume points with exact commands. The first one is
load-bearing and gets said plainly: tools/lcxl3-driver.py has never run against a
live SuperCollider, because sclang, scsynth and Ardour were all at zero when it
was written. Every claim about PLN playing his corpus on the new surface rests on
that one untested step, so it is resume point 1 rather than a footnote.

Also records what is deliberately left running (the audition server, plus the
firewall holes its LAN access needs and the ?set= key that cost PLN a listening
session), and what is parked because it is not mine to commit — four uncommitted
www files from a prior session's CosmicFest page work.

Three threads worth their own entries in the documentary trail.

032 — the LCXL3. Closes the board's twelve-day-old OLED question (arbitrary
128x64 bitmaps, ACKed per frame for animation), records the keystone result that
paint is DAW-mode-only, and the sixteen-index CC collision whose decisive case is
v3 #41 = button E5 against v2 #41 = the kick gate log 031 had just aligned 169
files onto. Plus two instruments that lied: aseqsend -s takes a FILENAME and exits
0 on 32 silent no-ops, and pgrep -c -f matched its own command line.

033 — fourteen tracks from one microphone. 12 of 14 named correctly off a
handheld stage mic with no stems and no log. Includes the three lenses, the three
failed tempo estimators, the same reference-size bias appearing in three separate
costumes, and PLN's ears beating my reporting twice because I printed 4 of 86
detections.

034 — the recorder nobody enumerated. Why CosmicFest has no session log: the unit
was installed 2026-07-29, never enabled, and absent from the authored inventory,
so nothing could assert it. Paid in three places, with a gate proved capable of
failing.

sample_tfidf.json re-run over the corpus; set_finder_locate.json is the 35-bank
pass (was 19) after MAX_DF rose from 6 to 40 on the strength of 1/df weighting.

The npz hash DB (2.3 MB, rebuilds in 39 s) and the per-recording query profile
are ignored: they are caches keyed on inputs, not sources. Noting the tension
deliberately — 'generated + gitignored + never compared' is exactly what made
preload staleness debut at a venue — so both are produced by an explicit
subcommand and their inputs are versioned.

fix(rig): the other two thirds of the gig-log fix, which 30fceb43's message claimed but did not contain

30fceb43 said the debt was "paid in three places" and shipped one file, the unit
itself. The inventory entry, the regenerated target and the hard gate stayed in
the working tree — so the commit that explains the fix and the commit that
performs it were different commits, and only one of them existed.

What is here:

  rig_units.py    gig-log joins SERVICES, so --ensure enables it and --status
                  reports it. 7 units, 0 problems. It was absent until now, and
                  that absence is the entire reason CosmicFest has no log: the
                  unit was installed 2026-07-29, never enabled, and nothing in
                  the authored list knew it existed.

  parvagues-rig.target  regenerated, now Wants 8 units.

  gig-up.sh       a HARD gate, deliberately not "is the unit active". A green
                  unit is not a recording — the process can be up while the
                  writer is wedged. It asserts a session file's mtime is within
                  20 s, i.e. it is writing NOW. Proved it can fail rather than
                  assuming: stopped gig-log, waited 25 s, gate failed at age
                  25s; restarted, age 1 s, passed.

Same class of error as the amend on c628415e earlier this session, where a message
described a midi-autoconnect fix the commit did not carry. Both times the message
was written from intent rather than from `git show --stat`.

PLN, auditioning CosmicFest: "at 22:42 its end of reose_rouge, theres a loud blip
noise, at 22:44.9 its the start of rose rouge, could we cut noise and blend
better?"

The lab could only ever answer one question — where does the next track start —
so garbage living in the 2.9 s BETWEEN two tracks had nowhere to go. It survived
as prose in a comment box, which no downstream tool reads.

`n` marks the playhead as noise and deliberately leaves the cut call untouched: a
blip between two tracks is not an opinion about where either begins, and forcing
it through the cut field would corrupt the one number the mastering chain trusts.
`N` clears them, because a mis-tapped defect marker you cannot remove is worse
than no marker at all.

They render in warm orange, distinct from every existing mark colour: those are
all CANDIDATES for a cut, and this one is the opposite — a place to avoid.

Exported from both the decided and skipped blocks, so a seam PLN rejects can still
carry "and there is garbage at 22:42". That combination is exactly what happened
here and exactly what the old export could not represent.

PLN: "wait you dont get the notes when i skip? DANG they have lots of info."

The exporter emitted skipped boundaries as bare integers:

    skipped: Object.entries(calls).filter(([, c]) => c.t === null).map(([k]) => Number(k))

so eight CosmicFest seams exported as `[2,4,9,10,15,16,17,18]` while the notes he
had typed into every one of them vanished. And a skip is not an absence of
judgement — it is usually a judgement that the SEAM is wrong, which is more
informative than confirming a cut time. What was lost included "theres no
blue_gold in this set, we're hearing do_it_right throughout", "there was no
gimme_acid in this performance", "theres no funk->piment transition! in this set
i playd piment once, then funk", and "it could be called Outro Dub Siren".

The notes were never actually gone: the textarea writes `{t: t ?? null, comment}`,
so a skipped call keeps its comment in state and in localStorage. Emitting
`skipped` as {id: {source, note}} therefore recovers notes ALREADY STORED, not
only future ones — PLN re-exports and gets them back verbatim. Verified the built
bundle carries it, after first mis-verifying: `grep -c` counts LINES and a
minified bundle is one line, so the honest count is 2 occurrences, not 1.

With his corrections the true set is 14 tracks, written to
judge_specs/cosmicfest-2026_setlist_ear.json as ground truth.

Scored against it, the three-lens pipeline named 12 of 14 tracks correctly and
labelled 81% of the 63 minutes, 85% of the labelled overlap correct. bombe_dj,
rose_rouge, ouais_je_funk, punkachien and livecode_parade landed at 100%.

The two failures are the same failure. `perfect` was called gimme_acid and the
improvised outro was called REVOLUTION, and both are reference-bound: crossmatch
can only choose among tracks it holds a prior render of, so audio from a track it
has never heard gets assigned to the nearest thing it has. All five "ghosts" —
blue_gold, desire, gimme_acid, quand_on_decolle, REVOLUTION — are that same
mechanism. It is a structural limit, and the fix is one render per track, not a
better threshold.

Also banks his ear-feedback in performance_notes.md, including two things no
analysis could have produced: a loud blip in the 2.9 s between two tracks (a
defect belonging to NEITHER, which the boundary tool currently has no way to
express), and why desire was dropped — "Clearly didnt play desire i was not found
of that closing at opal".

PLN, on hearing a rose_rouge sample inside a seam I had labelled quand_on_decolle:
"where is our samples mathcing? gosh, i should not do so excruciating details
myself. you have all the data bro." He was right. I had 86 offset-consistent
detections and printed 4, because `locate` reported each bank's single BEST window
and threw away temporal extent — which is the informative part.

What was hiding in data I already had:
  rose        -> rose_rouge            22:35-24:00 (max cons 0.81), and on to 31:30
  movie_paris -> something_about_drums   6:15 (0.62), 10:30 (0.49)
  take5       -> take_5_drops           32:10-35:30
  love_parade -> livecode_parade        55:20-56:10

So rose_rouge is continuously present 22:35-31:45 — a stretch I had split into
quand_on_decolle, blue_gold and UNRESOLVED. And something_about_drums sits in the
5:04-11:33 hole I reported as unclaimed, exactly where PLN said he played it
("im sure i played something about drums between bombe and do it right").

Then his second point, which is the principled fix: "its almost tfidf we should do
here. when we know rose sample is around a time slot, its a tell. when we see e.g.
_jungle_BreakS_, it's way less idf relevant."

Implemented as `fuse`: evidence for track T at time t is the sum, over detected
banks that T uses, of offset-consistency divided by that bank's df. A bank in one
track hands over all its evidence; a bank in eighty splits it eighty ways.

One refinement, from measuring rather than assuming: plain log-IDF is too flat for
this. jungle_breaks (df=80) carries 0.50x the weight of rose (df=2) — a 2x penalty
for being 40x more common, which would still let it dominate since it fires
constantly. 1/df gives 0.0125 vs 0.50.

Two normalisations that are not decoration. Per track, divide by the total 1/df its
banks could contribute, or a track referencing many rare banks beats a track with
one perfect tell — the reference-size bias in a third costume. And close gaps
before deciding: a rare sample fires intermittently INSIDE the track that owns it,
so `rose` at 22:35, 25:15, 28:15, 30:00, 31:10 is one track, not five appearances.

A NEGATIVE result worth recording. Weighting let MAX_DF rise from 6 to 40, taking
fingerprint coverage from 15/23 to 23/23 candidate tracks — and it added no
evidence at all: every new bank scored consistency 0.02-0.21 against a 0.30
threshold. I guessed reference duration was the binding constraint and that was
WRONG: correlation with best consistency is -0.144, and the three longest
references are among the worst detectors. Then the confound surfaced — suns_keys
belongs to blue_gold, which PLN did not play, so its low score is a TRUE NEGATIVE.
Failures and true negatives are indistinguishable without the setlist, so the
reason remains unestablished rather than explained away.

Also fixes two things that wasted PLN's time. The Boundary Lab query key is `set`,
not `gig` — bounds.tsx does get('set') ?? 'opal-festival-2026', so a wrong key
silently loads the DEFAULT document, and he auditioned OPAL's Sunset Forest seams
believing they were CosmicFest. The variable there is named `gig`, which is exactly
how I made the mistake: grepping found the word, not the key. And the generator
offered "bombe_dj -> bombe_dj" as cut #1, a seam between a track and itself,
because it read the un-merged segment file.

PLN: "dotn we have a webapp for listening to seams in a set? you could use it for
me to confirm your labels. reusable tooling pattern."

It does — armada/ui/bounds.html, the Boundary Lab. So this builds no second page.
make_bounds.py generates the document that page already reads, which means the
confirmation loop is the one that already stores calls per gig in localStorage and
already exports boundaries-<gig>.json.

That direction is the point. The three-lens fusion is a machine opinion: 11 of 18
segments have two lenses behind them, 4 are honestly unresolved, and the two rows
that were WRONG were caught by PLN's memory rather than by any score. An analysis
pipeline whose output lands in a report has nowhere to be corrected.

The contract was read from BoundaryLab.tsx, not assumed, and two details would
have been wrong if guessed: marks[].t is in MASTER time (the page subtracts
clipStart itself), and `url` is handed to WaveformPlayer with dur = clipEnd -
clipStart, so it must point at a CLIP of that length rather than at the whole
recording. Mark keys are colour-coded by the page, so the segments where a lens
OVERRODE the embedding get `takeover` — brand magenta, which its own comment calls
"the one to try first" — because that is exactly where an ear call is worth most.

Clips plus a mount rather than the whole file, following audio-mounts.json's own
reasoning: it maps /audio/<prefix>/ for BOTH vite dev and armada/serve.py
deliberately, since "a UI that only works under npm run dev is a demo, not a
tool". A 40s clip also loads instantly on a phone over LAN, which is where this
gets used. Peaks are normalised per clip because these are 40s windows of a room
mic whose level wanders, and a waveform you cannot see is not a waveform.

Verified rather than asserted: /bounds.html 200, the document 200 at 190 KB, a
clip 200 at 641 KB, and a Range request returns 206 with exactly 1024 bytes — so
seeking works, which is the whole point of auditioning on a phone.

PLN corrected two rows: he played rose_rouge and livecode_parade, not blue_gold.
The fusion now reaches both WITHOUT being told, which is the whole point.

29:57 crossmatch said blue_gold at a weak 0.44 margin; tempo measured 118.1
against blue_gold's declared 124 — a clash — and rose_rouge is declared 118,
with locate holding `rose` at 0.602 offset consistency. Two lenses override one.
54:59 the same shape: measured 130.0, gimme_acid declares 80, livecode_parade
declares 130, locate had `love_parade` at 0.399.

Both were only reachable because crossmatch STRUCTURALLY cannot name them.
rose_rouge played neither reference gig, and livecode_parade's .tidal was created
in the CosmicFest prep commit itself, so no prior render of it can exist anywhere.
A blind spot, not a tuning failure — and the fix is one render per new track.

The tempo lens took three attempts, and the first two measured nothing.
librosa.feature.tempo returned 107-130 for every segment of an 80-170 BPM set:
that is its log-normal prior centred on 120, not the music. Mode of inter-onset
intervals on the full mix returned 233-648 BPM, locking onto the hats rather than
the beat — and its apparent matches were hollow, because five octave multiples at
5% tolerance passes roughly a quarter of random values. Autocorrelation of the
40-120 Hz kick band works: bombe 123.9/124, punkachien 170.1/170, vague_de_crime
120.1/120, do_it_right 178.3/2 = 89.15/89. Four exact to 0.1%.

That validation is what licenses the overrides. An instrument which agrees where
it should is one whose disagreements carry information; without those four hits I
would be overriding a strong embedding on the word of an estimator I had not
checked (feedback_check_the_instrument_first).

I also had to fix my own fusion: counting each top-3 tempo candidate as a vote let
cafe_bouillant beat ouais_je_funk, which measured 120.1 against a declared 120 —
a perfect match demoted by an alphabetical tie. Tempo compatibility CONFIRMS the
embedding's proposal; it only overrides when it clashes AND a second lens agrees
on a specific alternative.

Four rows are now marked unresolved rather than confidently labelled. That is a
real answer: a confident wrong row costs more than a blank one.

PLN: "what gig-log didnt run that night? HOW COME? ... thats sad and needs
proper tech debt payment! We cant afford to miss that."

The answer is not a crash. gig-log.service was installed 2026-07-29 and then
left `disabled`, and rig_units.py mentioned it ZERO times. So the authored
inventory could not enable it, --ensure could not assert it, and gig-up never
gated on it. It ran only when somebody remembered to start it by hand — and the
sessions that exist, up to 2026-08-20, are exactly those manual runs.

Two known failure shapes, both already named in this repo, stacked:

The unit lived ONLY in $HOME, never in the repo. That is 4d9f1059 again, the two
reconcilers rescued from $HOME after five orbits reached no Ardour track. A file
that exists in one home directory is not infrastructure, it is a habit.

And it was missing from the one authored list. That is what 406a4610 was written
to end ("the list lived in three places"). An inventory only prevents the class
of bug it actually enumerates; gig-log was simply left off, so it inherited none
of the protection.

What was lost is not just thermals and xruns. It is the TRACK BOUNDARIES — the
gig log's `track` events are the real tracklist (reference_gig_log_is_the_tracklist).
Recovering CosmicFest's set afterwards took two independent DSP lenses, 30
reference renders, and it still leaves two unlabelled stretches. One always-on
1 Hz recorder costing 0.4% of a core would have made all of that unnecessary.

Paid in three places so it cannot recur:
  - tools/gig-log.service, versioned, symlinked into ~/.config/systemd/user
  - gig-log in rig_units.py SERVICES, so --ensure enables it and the generated
    parvagues-rig.target Wants it (8 units now)
  - a HARD gate in gig-up.sh

The gate deliberately does not ask "is the unit active". A green unit is not a
recording — the process can be up while the writer is wedged
(reference_sc_supervision, feedback_verify_the_plumbing). It asserts that a
session file's mtime is within 20 seconds, i.e. it is writing NOW. Verified it
can actually fail, because this repo already has a log titled "the checks that
could not fail": stopped the recorder, waited 25s, the gate failed; restarted,
age 1s, passed.

Still open, recorded not fixed: the HUD's eval-events.jsonl also missed the set.
It holds 21 evals on 2026-08-23 from 18:31-18:59 (prep at home) and then four
`pluie` evals at 22:14 with zero orbits, with a 3h15m hole across the gig itself.
Pulsar was running, so the likely cause is reference_pulsar_lazy_activation — a
reload leaves the package dormant — but that is a hypothesis, not a diagnosis.

Two independent lenses over a 63-minute handheld stage-mic MP3, for a night with
no stems and no gig-log. They agree where they can both see, and where they
disagree the reason is structural rather than mysterious.

Confirmed by both lenses, independently:
  0:00-5:04   bombe                 z=2.33 margin 0.67 + diams_dj 85% offset consistency (1056/1244)
  31:27-35:46 take5_drops           z=1.91 margin 0.58 + take5 cons 0.38
  8:54-11:28  something_about_drums              + movie_paris cons 0.49

Crossmatch alone, but with margins strong enough to stand:
  11:33-16:58 am_i_doing_it_right   margin 0.87
  18:13-22:32 you_my_sunshine       margin 0.82
  48:25-51:20 punkachien            margin 1.06  <- only findable because Montreuil supplied the render
  38:31-41:41 piment_bresilien      margin 1.19
  51:30-54:10 mafia                 margin 0.69
  57:29-60:29 vague_de_crime        margin 0.82

The two disagreements are the interesting part, because they are predictable.
crossmatch can only name a track it holds a prior render of, and  is
confident about two banks that have none: rose @31:20 at 0.602 consistency
(rose_rouge played neither gig) and love_parade @56:10 at 0.399 (livecode_parade
is NEW — its .tidal was created in the CosmicFest prep commit itself, so no prior
render can exist). Trust locate there. The fix for next time is one render per
new track and the reference set covers it forever.

Recorded as gaps rather than answers: blue_gold wins four short scattered
segments at margins 0.11-0.44, and that scatter is the signature of a fallback,
not a performance — material with no matching reference lands on whatever is
nearest. Segment edges come from a 45s median filter so they are +/- 20s and are
NOT cut points; bounds.html and ears do that job.

`locate` normalises by reference size. `crossmatch` did not, and the number said
so: correlation(reference length, seconds won) = +0.586. Ceci (524s) and Piment
(506s) won most of the set; WAP and REVOLUTION won nothing at all. The cause is
that per-track score is a MAX over that track's windows, so a 524s reference
simply gets more chances at a high max than a 154s one.

Same asymmetry, second occurrence, new location — which is the pattern in
feedback_count_what_you_bound: a bias survives a fix when the metric moves.

The correction turns "how similar is this window to track T" into "how UNUSUALLY
similar, for track T", by standardising each track's column over the whole
query. A track generically close to everything now has a high mean and wins
nothing; a track that spikes in one place wins there. It assumes each track
occupies a minority of the recording — true for 15-30 tracks over 63 minutes,
false for a 2-track set, so it is stated rather than buried, and --no-standardise
shows the raw bias.

Two more things, both from PLN's "almost the same lineup" observation:

Montreuil26's tracks_bandcamp adds 15 more renders, and six of them are tracks
OPAL never had — Jeudi Drill, PunkAChien, L'Or Bleu, Premier Septembre, Quand on
decolle, Techno Orage. That directly explains the two disagreements between the
methods: `locate` was confident about rose and love_parade, and crossmatch
mislabelled both, because rose_rouge and livecode_parade are absent from the OPAL
reference set and it can only pick the nearest thing it holds.

Six tracks now appear in BOTH gigs, so their names must merge or one track splits
its own vote and each half loses. canon_track does that with an explicit alias
table rather than fuzzy matching: a wrong explicit merge is auditable, whereas a
silent fuzzy merge of two different tracks would be invisible in the output.

Also caches the query profile keyed on mtime and window geometry, because
recomputing 63 minutes of chroma_cqt per run costs five minutes and this tool
exists to be iterated on.

The first scan reported raw hash collisions and I then analysed the noise. Every
bank occupied 375 of 378 time bins. Three things were wrong, each traceable to
prior art rather than to tuning:

Offset consistency was missing entirely, and it is half the algorithm. Wang's
2003 Shazam paper is explicit: real matches agree on a time offset, so the
(query_t, ref_t) scatterplot shows a diagonal and the offset histogram spikes.
Counting collisions without that step counts coincidences.

Fixed offset is wrong anyway for this material. Sonnleitner, Arzt & Widmer
(ISMIR 2016, DJ mix monitoring) allow the offset line a free slope, because a DJ
plays material at a different rate — and a livecoder changing setcps does the
same, across 80 to 170 BPM in one set.

Raw counts measure loudness. Measured, not assumed: 8 of 18 banks had their
global peak in the final minute, at 1.3-2.5x density. The finale is loud and
broadband, so it makes more spectral peaks, so it matches everything better.
Scores are now normalised by each window's own query-hash count and by each
bank's reference size.

But the real problem was the reference unit, and PLN named the fix: "comparing
to prior recs, of each track of the opal songs for example (almost the same
lineup in the end!)". A 0.4s dry one-shot cannot survive a PA and a 320 kbps
encode — too few hashes, below the detection floor by construction. Meanwhile
Prod/Opal26_master/tracks holds FIFTEEN ear-verified per-track renders, 154 to
524 seconds each, same performer, same sample library, same patches.

That changes the task from sample detection to VERSION identification, where the
literature is unambiguous: when audio is related but not identical you stop
matching exact time-frequency points and match sequences of features instead
(Serra et al. on covers, McFee & Ellis on structure). So `crossmatch` embeds
15s windows as MFCC mean+std, chroma and spectral contrast, matches by cosine
against every reference window, and median-filters over 45s because a track
lasts minutes and a one-window flicker is noise by definition.

Standardising before the cosine is not cosmetic: raw MFCC coefficients differ in
scale by orders of magnitude, so without it the first two — level and spectral
tilt — decide everything, and level is exactly what a room mic gets wrong.

The docstring says what it cannot do. The three cafe_* tracks are the same
instruments at nearly the same tempo and no timbral profile will separate them,
so the output reports a runner-up margin and flags thin ones: a win by 0.01 is
not a win.

Also included, from the custom-mode thread: the generated Components entry table
(40 of 48 controls need changing, all of row A already matches), and the sniff
that caught Components driving the device with documented feature controls —
9F 0B 7F then CC 30 = 6 — plus an undocumented cmd 0x05 whose read/write forms
match the audiocontrol project's reverse-engineered protocol.

PLN downloaded the CosmicFest capture and called it "an interesting test". It is:
a 63-minute handheld stage-mic MP3, and all three boundary lenses the toolbox
owns need something it does not have. Orbit-activity needs stems, there are
none. The gig-log `track` events are the real tracklist, but the 1 Hz recorder
never ran that night — newest session is 2026-08-20. Gap detection assumes a
set stops between tracks, and a livecoded set does not.

What is left is audio, plus one large advantage: we know what was prepped, so
this is matching over ~23 candidates rather than open discovery. PLN warns "the
set was slightly altered", so candidates are treated as candidates — presence
is strong evidence, absence is weak.

Two lenses, because neither is sufficient. Tempo finds seams but cannot name
them: five candidates sit at 120 BPM and three at 124, and tempo from audio is
only ever determined up to a factor of two. Sample signature names a segment,
and PLN pointed at exactly the right prior art — sample_tfidf.py already
computes which sounds IDENTIFY a track. take5 and love_parade are df=1;
jungle_breaks is in 80 tracks and worthless. 15 of 23 candidates carry a sound
rare enough (df<=6) to fingerprint; 19 such banks, 533k reference hashes.

Constellation fingerprints rather than correlation, because the reference is a
dry one-shot off disk and the query is that sound through a PA, a room, a
limiter, "ppl messed with it", and a 320 kbps encode. Peak constellations encode
only which time-frequency points stick up locally, which survives all of that.

My first attempt at extracting banks was wrong and the output said so: 9 tokens
across 23 tracks, every count 1, and a label reading "shares every bank" that
actually meant "nothing parsed". The regex looked for `s "name"` while the
ParVagues idiom applies a bare string — `$ "meth_bass" # n "..."`. The fix was
not a better regex, it was using the parser that already existed.

The docstring carries the limits because they are easy to launder: a detection
means the SOUND occurred, not that the TRACK played, since banks get reused
live. Recall is asymmetric — a track whose signature never sounded is invisible.
And vote counts are not comparable between banks, because a 582-file bank offers
far more chances to match than a 4-file one.

Also adds `lcxl3.py sniff`: capture raw SysEx in full. The custom-mode format is
undocumented, and Components writes modes to the device over SysEx — capturing
those bytes is the difference between a layout authored in lcxl_grid.py and one
merely stored in a web app.

The v3 and the 169 tracks disagree about what a CC means, and only one of them
is cheap to change.

Paint is DAW-mode-only. Tested rather than believed, in three steps with PLN
watching the surface: magenta on the MIDI port in standalone did nothing; the
same paint on the DAW port with DAW mode off did nothing; `daw on` followed by
the same bytes lit all 24 rings and 16 buttons. So the guide's "only available
once DAW mode is enabled" is a hardware fact, not an artefact of how the
document is organised.

But DAW mode's CC map is fixed, and it overlaps v2's with DIFFERENT meanings.
The map was read off the hardware, one control per row, not off the PDF's
low-resolution diagram: fader1 -> cc5 ch16, A1 -> 13, B1 -> 21, C1 -> 29,
E1 -> 37 ch1, F1 -> 45 ch1, shift -> 63 ch7.

    row   v2 (lcxl_grid)   v3 DAW
    A     13-20            13-20     identical
    B     29-36            21-28
    C     49-56            29-36     <- v2's row B numbers
    D     77-84            5-12
    E     41-44, 57-60     37-44
    F     73-76, 89-92     45-52

Sixteen indices collide. The one that decides it: v3 #41 is button E5, while v2
#41 is button E1 — the kick gate the whole #94 migration just aligned 169 files
onto. Renumbering would move the kick gate four buttons to the right, silently,
with nothing erroring. That is the same failure class b5ad8b6c was written to
end, so the corpus keeps its numbering and software absorbs the difference.

Three things make this cheap rather than clever:

SuperCollider's binding is `MIDIFunc.cc({...})` with no cc, channel or src
filter — only the number matters, so a pure renumber is sufficient and no
channel juggling is needed.

Every encoder row is still in ABSOLUTE mode (queried: rows 1/2/3 all read 0),
so a v3 encoder already behaves like a v2 pot. Relative mode needs an
integrator that owns the value — genuinely better, since it kills pot-pickup
outright, and it is where paint-by-value belongs — but it is a separate change
and `--relative` is left as an experiment that honestly warns the map no longer
applies.

The v2 numbers are DERIVED from lcxl_grid.ROW_CCS positionally rather than
retyped, so if the authored table moves, the translation follows.

Publishing a virtual port rather than resolving SuperCollider's once: SC runs
MIDIIn.connectAll a single time at boot, so a port that appears later is never
connected, and a binding resolved once is the rig's most repeated failure mode.
The driver re-asserts the aconnect link on a timer, the same shape as the two
reconciler units.

midi-autoconnect had the same stale-name bug: it hardcoded "Launch Control XL",
which matches neither v3 port, and since it routes aconnect's complaints to
/dev/null the failure was completely silent — Ardour stopped hearing the surface
with every check green. It now resolves the source, preferring the driver's
translated port over the raw device, and echoes what it picked once per change
rather than every two seconds.

4d9f1059 rescued these two scripts from $HOME, where they had been living
un-versioned, and committed them without the exec bit. The symlinks in
~/.local/bin resolved fine to a file systemd then refused to run:

  Process: ExecStart=/home/pln/.local/bin/tidal-ardour-autoroute.sh
           (code=exited, status=203/EXEC)
  Active: activating (auto-restart)

An auto-restarting unit reads as busy rather than broken, which is why
rig_units reported 'activating' and nobody chased it. Net effect: the autoroute
that puts twelve orbits onto Ardour's Tidal NN tracks has not run since 23 Aug
— the exact regression 4d9f1059 was written to end.

The recurrence has a cause, and it is repo config: core.fileMode = false here,
so git ignores exec-bit changes from the working tree entirely. That is why
4e0d63ae already had to fix the mirror image of this (+x on disk, 644 in the
index), and why chmod can never be the whole fix in THIS repo — it silently
does nothing as far as the index is concerned. `git update-index --chmod=+x`
is the tool that works.

Both halves done: chmod for this checkout, update-index for the index, so a
fresh clone is born runnable.

Not an extension of lcxl-leds.py, deliberately. v2 and v3 are different
protocols, not different constants: v2 is a template/palette SysEx driving
3-colour buttons, v3 has true RGB per control, a 128x64 OLED, endless encoders,
and a CC map that only exists in DAW mode. Folding v3 in would produce a file
that lies about both. When the numbering settles, lcxl_grid.py stays the one
authored table and this becomes its transport.

Every byte sequence in here is quoted from the official programmer's reference
v1.0, not recalled — RGB is 01h 53h <idx> <R> <G> <B>, the bitmap is 09h with
1216 bytes and a 7Fh terminator rather than F7h, and the feature CCs live on
channel 7 of the DAW in port.

Transport is python-rtmidi via mido rather than shelling out. aseqsend on this
system takes -s as a FILENAME: `aseqsend -p 20:0 -s "B0 25 05"` prints
'cannot open B0 25 05' and exits 0. A silent no-op, which is how a first paint
attempt can look like a hardware answer. lcxl-leds.py shells out that way
today, which is worth revisiting.

The subcommand that matters is `keystone`. The guide files 'Colouring the
surface' and 'Controlling the screen' inside the DAW mode chapter, prefaced
'only available once DAW mode is enabled'. If that is how the document is
organised rather than a hardware restriction, paint works in standalone and the
corpus keeps its v2 numbering — a 169-file difference. So it gets tested in
three steps with PLN's eyes on the surface, not assumed either way.

`sweep` exists for the same reason: the DAW-mode index map is a low-resolution
diagram in the PDF, so we light each index in turn and read the map off the
hardware.

PLN said snare was 'also a default tidalcycles CC0/public domain pack'.
Upstream disagrees: tidalcycles/Dirt-Samples tracks 52 files under sn/ and
zero under snare/. The 90-file snare bank is local and was unidentified.

His second memory was the one that paid — 'the very early tidalcycles docs
pointed me to that sample pack'. The banks come from slab.org/tmp/samples-extra.zip,
the Tidal Club course pack from Week 1 lesson 2. Proven by reading the zip's
central directory over a range request, so 113 MB stayed on the server:
SNARE0, SNARE119, KICK142, CLAP163 are all in it, and the local folder is
named samples-extra.

Three candidates died on dates and names, which is worth recording so nobody
re-runs them: Blood Sport prefixes its banks bs- and holds no SNARE*.wav; the
90s-sample-cds torrent was downloaded 2024-12-20, after these files' 2019-11-07
mtime; MF_Drums_Samples names its files BD_MF_Valve11.wav. And there is no
content-based route at all — AcoustID needs song-length audio, not 0.4s hits.

The uncomfortable part: this makes the ledger worse, not better. The pack ships
no licence for these banks — the only licence file in it is Blood Sport's own.
And snare's files carry ISFT 'Sonic Foundry Sound Forge 6.0', IENG 'TJ', ICRD
2003-08-30, i.e. 24-bit one-shots rendered on a 2002 commercial DAW. An official
course pack establishes provenance, not licence.

So kick, cleared on 2026-08-16 on the note 'TidalCycles official / samples-extra
CC0 pack', rests on the same unverified premise. Same pack, same absent licence,
but cleared is releasable and unknown blocks. One question to yaxu settles six
banks at once.

The board carried 'can third-party SysEx paint arbitrary text to the OLED?'
as UNVERIFIED, with a note that it mattered: HUD v2's alarms are derived
state, not control values, so a closed OLED meant the alarms stayed on
screen. The official programmer's reference settles it — arbitrary 128x64
bitmaps, and the firmware ACKs each frame specifically so you can animate.

Two more close the same way. LED brightness is CC 111 and non-volatile, so
open taste call #11 stops being an argument about whether a bypassed filter
should be bright and becomes a knob. And endless encoders emit deltas, so
pot-pickup does not exist to solve.

The new one is worse than the ones it closed. DAW mode is the only mode the
guide documents paint in, and DAW mode's CC map is fixed and PARTLY OVERLAPS
v2's with different meanings: v2's row-B knobs 29-36 are v3's row 3, and
v2's faders 77-84 are v3's relative-encoder row 1. Nothing errors. Controls
just move one row. That is the exact failure class b5ad8b6c spent 169 files
fixing, so that branch does not merge until this is settled.

Also retracted, with evidence: DIN is not our answer to the USB-hub single
point of failure. aconnect shows only Midi Through and the controller — this
machine has no MIDI DIN input at all, so DAW mode disabling the DIN outputs
costs nothing today.

And snare is still not cleared. 'Also a default tidalcycles CC0 pack' is a
name collision: upstream tracks 52 files under sn/ and zero under snare/.
The 90-file snare bank is local and unidentified, and still gates 4 tracks.

CosmicFest is closed as a mastering input by PLN's call. Five probes agree
nothing was captured to this machine; he had a stage mic and rates it poor.

PLN: "so many tracks still having ^42 instead of ^41 for kicks its confusing."

Remap phase 2 (5910aacc) column-aligned the board so column N IS orbit N, but it
was scoped to the FOURTEEN files of the OPAL set. Everything else still spoke
the layout from when gMask held CC 41, where an orbit's gate row started one
column late: d1 -> ^42, d2 -> ^43. button-column-audit found 169 such files,
every one of them shift +1 — a single layout generation, not a scatter of typos.

Layout-shifted files: 169 -> 0. Buttons on their own column: 35.7% -> 78.6%.

TWO SYSTEMIC FIXES IN migrate-columns.py, both found by running it on the whole
corpus instead of a setlist. Each refused a batch rather than writing bad
Haskell, which is the only reason they were cheap to find:

1. THE SEGMENT BOUNDARY WAS DEPTH-BLIND. A chain step ends at the next line
   starting with `$`/`#`, but a `$` inside an open paren is a CONTINUATION, not
   a new step. So a multi-line body truncated after one line, left depth 1, and
   the balance check refused the file. 10 of 169 were unmigratable. The boundary
   is now paren-aware, and the hit line is no longer assumed to BE a step start:
   `^NN` is routinely referenced from the middle of a body, so we walk back to
   the nearest enclosing step whose segment both balances and contains the hit.
   Negative depth was the tell that the anchor was too late, not that the source
   was broken.

2. COMMENTING OUT A `$`-STEP CAN UNDER-APPLY THE STEP ABOVE IT. Not a paren
   problem — an ARITY problem, and silent-eval is what caught it: 4 files
   stopped compiling while 165 were fine.

       $ midiOff "^57" (mask "<[t f]!0 ...>")   <- a function, still hungry
       $ stack [ ... ]                          <- its argument

   Comment the `stack` and GHC says "midiOff is applied to too few arguments"
   and the whole do-block dies, all twelve orbits — far worse than the
   cross-orbit trigger the comment-out was avoiding. `#`-steps stay
   commentable (`#` takes a ControlPattern, so a shorter chain is still
   well-typed); `$`-steps are now ANNOTATED and left live, and the FIXME says
   so, because an annotated line IS still firing.

VERIFIED against a pre-migration baseline, not against hope:
  * non-compiling tracks: 17 before, 17 after, and the SETS ARE IDENTICAL —
    zero newly broken, zero newly fixed. All 17 predate this work.
  * silent orbits: the same 19, in the same tracks, only line numbers moved.
  * pvlint: 30 -> 26 errors, no new error signature. Warnings 996 -> 1041: the
    +45 are the annotated-but-live `$`-steps honestly reporting that they still
    reach another column. Errors down, honesty up.
  * fix-button-roles: 3 clean role rewrites applied, then 0 remaining. The
    role report is otherwise unchanged from HEAD, so the migration introduced
    no gate/gesture inversion — the class only PLN's ear catches.
  * migrate-columns --plan re-run: 0 moves. Converged.

Left for a second pass, deliberately: 118 sites where an orbit's two own-column
buttons carry the same role (e.g. two gestures, no gate). Those are not
inversions — with no gate there is nothing to swap, and the grid gives d1-d3 one
button anyway. The count rose from 74 because column-aligning the buttons is
what made them VISIBLE; they were unevaluable before. gSel (#54) is the fix.

PLN: "we gotta ensure these are unified proper gig single service or package
easy to maintain/add things to."

tools/rig_units.py is now THE inventory. Three consumers, no re-typing:
the Bridge panel imports SERVICES, gig-up.sh reads --ensure, and
parvagues-rig.target is GENERATED by --target. Same shape as lcxl_grid.py (#97),
for the same reason: the list was previously a hand-typed table in bridge/rig.py
(5 rows, missing parvagues-bridge), a hardcoded loop in gig-up.sh (4 names), and
whatever [Install] each unit carried. Adding a unit to the rig is one row.

Two real bugs closed:

* gig-up.sh only ever ran `systemctl start`, never `enable`. A start fixes
  tonight and changes nothing about the next login — exactly how
  tidal-ardour-autoroute sat `disabled` while every pre-gig check passed.
  --ensure does both verbs, per-unit boot policy: the reconcilers are "login"
  (they idle, hold no ports, make no sound), parvagues-sc stays "on-demand"
  because a login must not start SuperDirt.

* `is-enabled` returning "linked" means NOT enabled — it reads like a healthy
  word. --status says so in words instead of printing systemd term.

Also learned the hard way while doing this: a unit file symlinked from
~/.config/systemd/user into a FEATURE branch vanishes on `git checkout`, and
`systemctl disable` on a linked unit deletes the symlink itself. Live infra
files belong on master; both units are there now.

systemctl --user start parvagues-rig.target  # the single handle