feat(control-lens): the noise floor comes from REPEATED baselines, not one lucky repeat
The closing A-again capture gives a single estimate of how much the signal moves on its own, and on the first real run that estimate was wrong in the direction that matters. Two captures of d2 at the SAME control setting read 1.6 and 2.4 onsets/s — 33% apart, which happened to equal gMask's entire measured swing — yet the closing capture matched the opening one exactly, so the tool reported drift 0.0% and called the control EFFECTIVE. One repeat can agree with the first reading by luck. Now the baseline is captured --repeats times (default 2) BEFORE the control is touched, and the spread between those captures is the floor a swing has to beat; the closing A-again is combined with it via max(). This is why d7's ply came back INCONCLUSIVE (swing 13.3% vs drift 10.0%) instead of EFFECTIVE — which is the right answer: across two runs that same control read -18% and then +3.3%, i.e. noise. The rule this encodes: on a livecoded rig the material is not stationary. Patterns written as `"~ c . <[~ c ~ c] [<c ~ ~ c> ...]>"` play a different bar every cycle, so a before/after difference is evidence of nothing until you know how big a difference the music produces unaided. Measuring the control without measuring the noise is how you end up certain about a knob that does nothing. Also lands the #66 log (armada/tasks/018) with the full per-track and per-control tables, and the three findings still open: gMask's swing is not clear of its own variance, a reproducible ~15s settle lag after a control returns to rest, and Ardour's xrun counter climbing while SuperCollider's does not.
Showing
Please
register
or
sign in
to comment