docs: correct the visuals plan, and record the jig decision

The visuals entry was wrong in its premise, and the correction matters more
than the task: xps22 came up and showed that `visuals/scenes/` already exists
(14 mp4s, 197 M), that the HUD's scenesDir already points at it, that the gifs
were already compressed on 2026-08-29, and that committing them was
DELIBERATELY rejected in .gitignore with the reason written in. The "16 dangling
url refs" are working as designed — scenes.js:_preferDerived() documents that
the header points at the SSOT source and the HUD substitutes the derived mp4.

So the plan "one home, compress, rewrite refs repo-relative" proposed doing
three things that were already done or already decided against. The remaining
work is a 197 M copy, and the entry now says so. Kicked a fence before reading
why it was there.

Jig decision 1 answered: ONE STABLE JIG, swept every time. Recorded with the
two consequences that follow — ARDOUR_SESSION stays fixed, and "self-contained
per gig" must now come from take metadata, which folds question 2 into it.

Also opened: the Ardour fader feed's verified findings (Ardour has already
learned CCs 13-16; only "midi-feedback"=0 withholds the values; Midi Through is
a loopback so the feedback leg needs its own port), ../tidal-ears not being
cloned here, and pytest being absent from the very interpreter the rig runs.

backlog.md

@@ -2044,22 +2044,48 @@ url: "/home/pln/Work/Art/GLITCHWAVE/outputs/bg_live4.gif"
 Floated during the session that got rose_rouge playing, not done. Full context:
 `armada/tasks/completed-archive.md` (top entry) + `docs/2026-09-06-ardour-fresh-jig.md`.
 
-## Blocking the visuals last mile
-- **Every scene asset is missing on this box.** `rose_bloom.gif` is nowhere under
-  `~/Work` or `~/Pictures`, and `~/Work/Art/GLITCHWAVE/` does not exist at all — so
-  **16 dangling `-- url:` refs**: 11 `.tidal` files point into `~/Downloads` (transient,
-  which is how rose_bloom vanished) and 5 into `GLITCHWAVE/outputs/`. PLN: "lets move it
-  to one repo ahah and ensure gifs are decently compressed". Plan: one home
-  (`visuals/scenes/`), compress before committing (gifs in git are permanent weight —
-  check whether the HUD accepts webp/mp4 first), rewrite all 16 refs repo-relative so a
-  fresh clone gets visuals like it gets code. **Blocked: needs the files off xps22**
-  (`192.168.1.3`, "No route to host" — PLN restarting it) or the Freebox.
+## Visuals last mile — it is a SYNC, not a restructure
+
+**Correction (2026-09-06, after xps22 came up).** The entry here previously said
+"one home `visuals/scenes/`, compress the gifs, rewrite the 16 refs
+repo-relative so a fresh clone gets visuals like it gets code". All three were
+wrong, and two were already decided the other way:
+
+- `visuals/scenes/` **already exists** on xps22 — 14 mp4s, 197 M — and the HUD's
+  `scenesDir` default already points at it (`package.json:101`).
+- The gifs are **already compressed**: `rose_bloom{,_fast,_noir,_rebloom}.mp4`
+  are 65-204 KB, encoded 2026-08-29.
+- Committing them was **deliberately rejected**: `.gitignore:53-56` ignores
+  `visuals/scenes/` with the reason written in.
+- The "16 dangling `-- url:` refs" are **working as designed**. See
+  `scenes.js:_preferDerived()`: the header points at the SSOT source (a
+  GLITCHWAVE gif, a Downloads loop), the source stays put, and the HUD
+  substitutes the derived `<stem>.mp4` from scenesDir. Nothing to rewrite.
+
+So the only real gap is that this box lacks the derived media, correctly, because
+it is gitignored. **Remaining work: finish the copy.** The first attempt got 3 of
+14 files (7.2 M) before xps22 dropped off the network mid-transfer, dying on the
+120 MB `decollage.mp4`; `rose_bloom*` did NOT land. Retry with `-H --partial`:
+`decollage.mp4` and `decolle.mp4` are hardlinks of the same 120 MB file, so `-H`
+alone cuts the transfer from 197 M to ~77 M.
+
+    rsync -aH --partial --info=progress2 \
+      xps22.local:'~/Work/Sound/Tidal/visuals/scenes/' visuals/scenes/
+
+Also absent on this box and worth a decision: `~/Work/Art/GLITCHWAVE` (3.1 G, 24
+gifs, 18 mp4s) is the SSOT *source* tree, needed only to re-run
+`npm run scenes:ingest`, never to play. Do not sync it to the gig laptop unless
+we intend to author scenes there.
 
 ## Sound / mix
-- **`Tidal 12` fader is at `-inf dB` — SILENT.** Caught by gig-up's readiness gate.
-  rose_rouge's d12 is "LE JAZZ C'EST DU PIANO", so that orbit reaches nothing. Decide
-  mistake-vs-intent, then `tools/fader-baseline.py --restore` or `--capture` (Ardour
-  closed). Same shape as decision 1 in `armada/tasks/043`.
+- ~~**`Tidal 12` fader is at `-inf dB`**~~ **DONE, and the framing was wrong.**
+  PLN: "tidal 12 -inf is random i might turn on/off any fader its not signal
+  throughout perf it mioves always and i save random". Fader positions at save
+  time are arbitrary, so there was nothing to decide. Measured: **9 of 12**
+  faders had drifted, five to -inf. `gig-up.sh` now runs
+  `fader-baseline.py --restore` in the Ardour-closed window, full restore to the
+  2026-08-02 baseline. Nothing further unless the baseline itself should move
+  (`--capture`).
 - **`/usr/local/sbin/perf-audio` not deployed**, so gig-up cannot set performance mode
   and the box played at `gear: None, mode: silent` with the CPU capped at powersave.
   Needs the root-owned perf.sh + sudoers rule (README "Deploy mode-switching").
@@ -2088,3 +2114,41 @@ Floated during the session that got rose_rouge playing, not done. Full context:
   would move it off the Qt6 it was written and tested against.
 - Untracked: `start_minimal.scd`, `sandbox/debug.tidal`. Also `BootTidal.hs.broken` and
   `BootTidal.visuals.broken.hs` are still sitting in the repo root.
+
+## Opened 2026-09-06 (second pass)
+
+- **The Ardour fader FEED for the d9-12 level rings is designed, not built.**
+  PLN chose the live feed so those four rings glow by real audibility. Findings,
+  all verified on the running rig:
+  - Ardour has already LEARNED the right CCs: `<MIDIControllable>` bindings in
+    `~/.config/ardour8/config` map `0xd 0xe 0xf 0x10` (13-16, the d9-12 level
+    knobs) and `0x4d..0x54` (77-84, the d1-8 faders). All twelve levels bound.
+  - The only thing withholding the values is one global flag:
+    **`"midi-feedback" value="0"`**. Ardour writes its config on quit, so this
+    must be set with Ardour CLOSED (same window as the sweep and the fader
+    restore) or ticked in its GUI.
+  - `ardour:MIDI Control Out` exists and currently has NO connections.
+  - **The hazard**: the driver reaches Ardour via `131:0 -> 14:0 (Midi Through)
+    -> ardour:MIDI Control In`. Midi Through is a LOOPBACK, so pointing
+    feedback at it would echo the driver's own CCs back into itself. The
+    feedback leg therefore needs its own dedicated virtual input port
+    (`self.virt` is output-only), plus a reconcile leg to hold the link — the
+    same "bindings are re-asserted, never assumed" pattern as `reconcile()`.
+  - Driver side is already prepared: `self.ardour_seen` exists and
+    `ring_colour(value_known=...)` keeps those rings flat until it fills, so the
+    feed can land without touching the paint laws.
+  - Needs Ardour restartable to test, which is why it was not built blind: an
+    unverified detector is the one thing this rig's doctrine forbids.
+
+- **`../tidal-ears/` is not cloned on this box.** `tools/analyze_samples.py` is a
+  committed symlink into it, so it dangles — which broke the whole
+  `test_one_tidal_parser` ratchet at COLLECTION until the guard was taught to
+  skip unreadable paths. Same portable-rig gap as GLITCHWAVE and visuals/scenes:
+  the sisters CLAUDE.md documents are not fetched by any install step.
+
+- **pytest is absent from the rig interpreter.** The suite runs under pyenv
+  3.11.10 (which lacks `mido`), so 3 `test_lcxl3_display.py` tests fail for
+  environment reasons, while `/usr/bin/python3` — the interpreter every systemd
+  unit actually uses, and the one that HAS mido — cannot run pytest at all. The
+  rig's own hardware tests are therefore unrunnable where they matter. Same bug
+  class as the rig-doctor fix: asking the wrong interpreter.

docs/2026-09-06-ardour-fresh-jig.md

@@ -108,10 +108,20 @@ sort of drift a plan should catch rather than a gig.
 
 ## Open questions for PLN
 
-1. **Per-gig sessions, or one stable jig?** This plan keeps the single stable
-   path. The alternative — a new session per gig, named by date, instantiated
-   from the template — makes each gig self-contained and the sweep trivial, at
-   the cost of touching `ARDOUR_SESSION` and anything assuming a fixed path.
+1. ~~**Per-gig sessions, or one stable jig?**~~ **ANSWERED 2026-09-06: one
+   stable jig, swept every time.** PLN chose it, so `ARDOUR_SESSION` stays the
+   fixed path it is today and nothing has to learn to resolve "which session is
+   live". Routing and faders are permanent fixtures of that one session; only
+   the audio leaves. Two consequences worth writing down before building:
+   - The invariant is now enforceable in one place, and it already half-is:
+     `gig-up.sh` clears dead references AND (as of this date) restores the fader
+     baseline, both in the Ardour-closed window. The stem sweep is the third
+     step in that same window, not a new mechanism.
+   - "Self-contained per gig" has to come from the swept stems' own naming and
+     take metadata instead of from the session directory. That folds question 2
+     into the answer: the sweep must hand off to `take-master.py` /
+     `take-lens.py`, because they are now the ONLY thing that will remember
+     which gig a stem belonged to.
 2. **Where do swept stems land?** The Freebox mirror is the established target
    (53G already there). `tools/take-master.py` and `take-lens.py` exist; the
    sweep should hand off to them rather than reinvent take handling.