Aiming a capture at a transient

--strip N samples the clip at N evenly spaced hops. That is the right question for “what does this look like over the clip” and the wrong one for “what does the frame the gate fired on look like” — and the two get confused because a strip looks thorough.

The arithmetic: under --signal click:120, onset crosses 0.75 on 7 hops out of 375. An evenly-spaced strip of 8 lands on one of them by luck, and when it misses, the capture shows a preset whose reseed never fired — which is indistinguishable from a preset whose reseed does not work.

So the level table names the peak hop and --at takes it:

# 1. What does this clip do, and where?  -> "onset peaks at 1.000 on hop 46"
cargo run -p standalone --example shot -- --preset-file presets/attractor_ink.toml \
  --signal click:120 --strip 8 --out over-the-clip.png

# 2. Now capture the transient itself, and the frames either side of it
cargo run -p standalone --example shot -- --preset-file presets/attractor_ink.toml \
  --signal click:120 --at 44,46,48,54 --tier rich --out the-reseed.png

Hops are indices from hop 0 of the clip — the same numbering the level table reports. Order is yours (a before/after pair reads left to right), duplicates are an error, and a hop past the end of the clip is an error rather than a silently missing tile.

--signal click:120 reaches every shipped reseed gate, and always did. ADR-0066 and design-backlog 0050 both state the opposite — that the synthesized clip’s onset never clears 0.56, let alone attractor_clifford’s 0.75. That was true on the raw onset scale and was invalidated by ADR-0049’s peak normalization, whose attack is instant: an isolated transient reads 1.000 on the hop it arrives, whatever its absolute magnitude. Measured at Plan 0057 Phase 1, click:120 produces 7 clean rising edges over 0.75, one per beat. The gate was never the problem; aiming at it was.

Which kind to reach for, for a gate rather than a level:

kind	onset min / mean / max	as a reseed stimulus
click:<bpm>	0.000 / 0.033 / 1.000	the one to use — 7 isolated edges over 0.75, one per beat
dynamic:<bpm>	0.001 / 0.153 / 1.000	12 edges, in amongst real band dynamics
noise:<seed>	0.826 / 0.953 / 1.000	wrong — pinned above every gate, so an edge-triggered binding fires once and never again, exactly as --set onset=1 does

Trap 3 — --set leaves the 64-band spectrum silent, so bin(x) reads 0. --set writes the analysis frame’s scalars; there is no key for the log-band array, and AnalysisFrame::default() leaves all 64 bands at zero. So under any --set capture:

• every bin(x) call in an expression returns 0, whatever bass/mid/treb say, and
• the whole spectrum system draws its base resting comb and nothing else — the readout is inert, which looks exactly like a broken preset.

This is not a bug in --set (it writes what you ask and nothing else); it is the one part of the frame it cannot reach. bin(x) and the spectrum system have to be verified through --signal or --audio, both of which run the real analyzer over real samples and therefore populate the array:

# The band array through the real FFT - the readout actually moves
cargo run -p standalone --example shot -- --preset "Halo" \
  --signal chord --strip 3 --out comb.png

--report builds its stimulus frames in code rather than from --set, and those do light the band array (each named band lights the slice of the log spectrum it summarises), so the report’s numbers are real for a spectrum preset.