feat(tools): gig-preflight — assert the rig is ready BEFORE you play
The rig is heavily instrumented and nothing ever looked. gig-log has been
sampling freq, per-core cpu, throttle deltas, fan rpm, per-process cpu/RSS and
xruns at 1 Hz for weeks (512k samples in the current file), yet every failure
this session was discovered by feel, mid-session, at the worst moment. This is
the looking.
Every check exists because it silently cost a real session on 2026-09-04/05:
* Composed an hour at 800 MHz because the Bridge's perf-watch reasserted
`silent` every 30 s, undoing each fix within half a minute. Cost 2671
xruns/hour. Every throttle counter read zero — with HWP, epp=power makes the
CPU *choose* its floor, so the failure has no error message.
-> check_perf, check_regime_agreement
* `gluck` refused to load for 90 minutes. The symlink was perfect; sclang had
been up 6 days and loadSoundFiles scans folder NAMES once, at startup, so a
bank added later is invisible. Pulsar's "restart SuperDirt" button is a no-op
here (SuperDirt is a systemd service, not Pulsar's child) and honestly
reported 142 h uptime while looking fine.
-> check_superdirt_fresh
* Samples/crutch was a symlink pointing at ITSELF since Oct 2025. Dead bank,
no complaint from anything.
-> check_sample_integrity
* A new LCXL3 showed default LEDs because the resolver name-matches the mk2
product string, while the watcher logged "-> 27 controls" and looked healthy.
-> check_midi_surface
Three design rules, all learned the hard way:
1. Green is not evidence. `active`, exit 0 and silence all lied during this
session, so every check reads the LIVE value from sysfs/procfs/the device
and prints the number it saw. No check trusts a status.
2. Every FAIL carries its fix as a runnable command. A preflight that reports
a problem without the remedy just adds a step between you and playing.
3. It never mutates the rig. Read-only by construction — a preflight that
writes is one more un-arbitrated writer, the exact bug class it detects.
16 checks. First run found 1 fail + 3 warns, including a genuine xrun rate of
2224/hour with every CPU line green — a problem we had not noticed and which the
clock fix does not explain.
Known over-sensitivity: check_xruns uses the raw total, and two of the top three
sources (input.hydra_in, the built-in Speaker sink) may not be in the live
monitoring path at all. Xruns on an idle sink inflate the count without being
audible; it should weight by nodes actually in the path.
gig-preflight.py human report, exit 1 on any FAIL
gig-preflight.py --quiet only WARN/FAIL, for gig-up.sh
gig-preflight.py --json for the tray/Bridge
Showing
tools/gig-preflight.py
0 → 100644
Please
register
or
sign in
to comment