Third session running, he raised faders by hand and hit Ctrl+S, then asked the
right question:
"ok raised and saved 10 and 12, saved, check again.
but ideally we should not depend in that?"
He is right. The gate CAUGHT the problem all three times — the dependency was
never on the check, it was on him having hands free to fix it. On a Saturday at
19:00 in a field that is not a dependency you want.
THE MECHANISM, now understood: the Ardour session IS the boot state. He ends a
set with the faders pulled down, which is what you do at the end of a set,
Ardour saves that, and the next launch comes up silent. Today's save had NINE of
twelve at -inf, and all 15 setlist tracks would have lost an orbit — d10 carries
the riser convention (#33), so all ten risers would have been silent and he
would never have heard them go.
tools/fader-baseline.py: --capture / --check / --restore.
WHY THIS IS ALLOWED TO WRITE FADERS when the standing rule says never to. The
rule exists for three reasons — it desyncs the file from the physical desk,
CC77 down is total silence, and levels are MUSICAL INTENT an agent must not
invent. All three are about INVENTING a level on a LIVE desk. This does neither:
it replays a value PLN set and approved (stamped with date and source session),
it refuses to write under a live session so the desk always wins, and it can
only address routes named "Tidal NN" — Master, monitor and busses are not
reachable by this tool at all. It writes a .bak first, because a corrupted
performance session six days out is not a recoverable mistake.
--capture REFUSES if any fader is silent. Capturing end-of-set silence as the
baseline would enshrine the exact bug this undoes.
Baseline captured while the mix was green: 12 faders, 01 at 0.0 dB through 09/12
at +6.0 dB.
PROVEN BY MUTATION on a COPY, never his live session: pull the same nine faders
to 0.0, --check reports all nine with their baseline deltas and exits 1,
--restore puts them back, and check-mix.py independently agrees every orbit
reaches master again.
AND THE TEST FOUND A REAL BUG IN THE GUARD. The first version asked "is ANY
Ardour running" — the safe-LOOKING answer and the wrong one, because it refuses
to repair a session nobody has open, and it made the restore path untestable
while his live session was up. The hazard is writing UNDER a live session, so
the guard now matches on the resolved session path. Still refuses his open one;
no longer refuses everything.
Wired in two places: a HARD "fader baseline" check in the gate, and a --converge
action that restores automatically when Ardour is closed. gig-up: GO, and
--converge is a clean no-op on a healthy rig.
