Instruments gate: 62 of 83 CPython comparisons fail at the pin — the CPython target moved under goldens captured 2026-08-26

[bdbarnett]

Found by the board session on 2026-09-03 while verifying the split, checked before attribution. Recorded so the first public release is cut knowing it, not discovering it.

What the gate says. tests/parity/run_instruments_parity.py --verify, all four batches, run in a fresh scratch venv whose pydevices-audioif was installed from git+file://…/audioif@d84470a — the exact AUDIOIF_PIN commit, asserted via direct_url.json — with lib/audioinstruments and lib/audioeffects installed editable from this tree at 7befee5:

166 comparisons, 62 failures, 10 rebuilt (not compared)
micropython: 83 ok, 0 fail
cpython:     21 ok, 62 FAIL

The repository's own .venv reproduces the same 62 (its audioif wheel was built 2026-09-02 09:18, after the pin moved at 07:35 — it is not stale; this was the first thing checked). The gate is workspace-local and no workflow runs it, so CI is green while this is red.

Which ones. Every failure is on the cpython interpreter; every micropython comparison passes. Failing: the 40 melodic modules andromeda arp2600 b3 clavinet cp70 cs80 cz101 d50 dx7 emulator2 farfisa fs1r jp8000 juno106 jupiter8 k2600 karplus microwave minimoog ms20 ms2000 music_easel nord_lead obxa odyssey pianet polysix ppg_wave prophet5 prophet_vs rhodes sh101 solina taurus tb303 virus vox_continental vp330 wasp wurlitzer, plus the private batches brass_stabs choir fm_bells glass impact keys pump_pad riser strings supersaw (Automata) and bells brass_high choir hits horns lead moog_bass pad_glass riser strings_high strings_low timpani (Perihelion). Passing on cpython: fairlight mellotron vl1 acid arp_fast claps glitch hats kick organ polyseq reese shaker snare sub_bass texture toms arp pad_warm shimmer sub_drone.

Why, as far as the evidence goes. The melodic goldens were last captured on 2026-08-26 (1ae2c10). Since then the pin took four audioif fixes, and three of them change only the CPython target (b420dac oracle-exact press semantics and filter cascade, 52a1d4e ring modulation, d84470a live envelope reassignment; afb6b71 touches both targets — and cmods/bin/micropython, built 09-02 01:16, predates it by 13 minutes, so the micropython side may be green for the wrong reason). A comparison is always within one interpreter, so this is the stored digests doing their one job: noticing that the engine moved under both sides on CPython. The 21 that pass are the ones whose probe sequence never re-presses a note or reassigns an envelope.

What it is not. Not the ceiling change (edits at 14:44, wheel at 09:18; and 14 was already the CPython value). Not the split (no lib content changed). Not a stale venv.

The decision (Brad's). The board's rule is that parity digests re-capture only with independent oracle evidence cited. The evidence here is the four commits themselves — each landed with audioif's oracle-diff gates green, and b420dac/d84470a are oracle-exact by construction — so a --capture-old of the CPython digests for these batches, done once against the audioif release tag with the provenance recorded in the golden's commit message, is what the rule allows. Until that happens, the gate is red for the first public release and tests.yml cannot see it. The board session recommends folding the re-capture into the post-tag replay step (same provenance discipline: installed audioif asserted equal to the tag) and re-checking the afb6b71 question by rebuilding cmods/bin/micropython first.

[bdbarnett]

Correction, after the accuracy session split the failing set and I checked it against audioif's history: this is not a 60-module re-capture question. It is "audiocomponents' parity artifacts are a day behind audioif's", and most of it is already decided.

The 62 comparisons are 60 distinct modules. Against audioif's two parity commits from this morning:

• 37 are in audioif's 40-entry retirement (79ae343, 12:15 today — the instruments af837de changed on purpose). audiocomponents' copy of run_instruments_parity.py still carries only the ten Phase 1 drums in REBUILT, so the retirement never reached this side when the gate was "moved" here (audioif 630db0e deleted its copy on the claim that this side's had moved on; for the runner and goldens that was half true). Re-capturing these would bless a deliberate change as a regression baseline — the exact failure the retirement list exists to prevent — and it gets worse the moment af837de is replayed here, because then the gate goes redder and reads as the replay breaking something. The action is to carry the 40-entry REBUILT (and audioif's retirement-vs-re-capture wording) across before the replay. That carries Brad's 79ae343 decision to the copy it was always about; it is not a new blessing.
• 15 of the remaining 23 are in audioif's f7a370a (12:07 today — the 19 CPython digests stranded by b420dac, four of which are drums retired here): farfisa minimoog vox_continental fm_bells glass impact strings bells brass_high hits horns pad_glass strings_high strings_low timpani. Those digests were captured with the oracle evidence the rule asks for (tests/test_cpython_press_semantics.py against bin/circuitpython) and can be carried across verbatim once AUDIOIF_PIN moves to the release tag — see the next point.
• 8 remain unexplained: brass_stabs choir keys lead moog_bass pump_pad riser supersaw (private batches only; choir and riser are in both). The likely cause is the engine gap between the pin and audioif's HEAD: aed9336 (09-02 15:23, "give a released note's channel back before its tail ends") is a CPython-target change that sits after d84470a, and audioif's goldens were captured with it in. Dense private compositions are where release-tail reclaim changes allocation. If so they pass at the tag and fail at the pin, which is one more reason nothing is re-captured against d84470a.

Plan (board session, sequenced with audiocomponents#2): after audioif is tagged and the pin moves to it — (1) carry REBUILT and the wording across; (2) carry the 15 digests; (3) run the gate at the tag with both legs; (4) whatever survives of the 8 is investigated, and re-captured only with evidence named; (5) only then replay af837de, with the ten drum kits asserted byte-identical. One local commit series, read by the accuracy session before Brad's ear. Nothing on this side moves before the tag.

[bdbarnett]

Closed decomposition — nothing here for Brad. The accuracy session confirmed the aed9336 hypothesis for the last 8 by rendering each module twice against the same compiled _audioif.so, once with the pin's synthio.py and once with HEAD's (that commit is pure Python): every pin render hashes to the gate's reported "actual", every HEAD render hashes to the stored golden, character for character, and the divergence starts at block 14 in each — where a released note's tail ends, which is the commit's mechanism. So the 60 is:

37  runner missing audioif's 40-entry REBUILT (79ae343)
15  goldens missing f7a370a's re-captured cpython digests
 8  the pin predates aed9336; the release tag contains it

Nothing to re-capture, nothing to re-bless. The carry-across (REBUILT + wording + the 15 digests) is pre-built as a patch that applies clean to 7befee5, and lands after AUDIOIF_PIN moves to the tag, together with the fix for #25 — the runner discards the caller's PYTHONPATH (:114 assigns instead of prepending), which is the same blind-checker defect audioif fixed in aa51f24, and which nearly turned this confirmation into a "refutation". Acceptance for that fix, per #25: a planted synthio.py that only raises must make the run FAIL.

[bdbarnett]

Audit 2026-09-04: partially addressed — do not close on the CPython number alone.

Done: the three-part carry-across landed as planned, and the CPython leg was re-run in the repo's own environment (pinned at v0.2.0 / ec3c67f, matching AUDIOIF_PIN): 3 comparisons, 0 failures, 50 rebuilt.

Remaining: the gate as a whole is not green. The CPython leg compares 3 of 53 modules; the MicroPython leg fails 3 of 3; and the private half cannot run at all, because its sources were deleted — 40 golden entries, 8 of which were never re-verified after the pin moved.

Two decisions are needed before this closes: what happens to instruments_private_automata.json and instruments_private_perihelion.json (re-capture against the library instruments the soundtrack now uses, or retire them), and the N=14 MicroPython binary question, so the MicroPython leg has a reference that does not move with the port.

[bdbarnett]

The MicroPython half of this gate is red now too, and it is not the same problem. It is the voice ceiling. Do not fix it by re-capturing those digests — that would quietly bless a sound change you have not heard yet.

Found while verifying audioif#27 on 6 September. The last line of this issue said to re-check the afb6b71 question by rebuilding cmods/bin/micropython first. It has since been rebuilt, and here is what that shows.

What the gate says now

ok       farfisa        cpython        e23b4facfa530556
FAIL     farfisa        micropython    be1eba7a4fcd61e1 != 57645f34bd28d93b
ok       minimoog       cpython        44d9926fd218b52c
FAIL     minimoog       micropython    ae7734259e2b15a3 != f12729624852eed8
ok       vox_continental cpython       e4bbb90d6b078700
FAIL     vox_continental micropython   dc7ae0ac7c72f76b != 705dde35d9fea220

The cpython leg passes for these three — the reverse of what this issue records — because they are among the 21 that were already passing.

Why

The two legs are running at different voice ceilings.

• This repository installs audioif at v0.2.0 (ec3c67f, 3 Sept 16:03). That snapshot caps a Synthesizer at 14 voices. That is the leg the digests were captured against.
• audioif 8f8b10d raised the cap to 64 at 21:10 that evening.
• cmods/bin/micropython was relinked at 23:07 the same night for the jpegio work, and picked the new cap up as a side effect. Asked directly, it answers 64.

So the MicroPython leg has been rendering at 64 against digests captured at 14 ever since, and nothing in either repository's CI can see it.

Proof it is the ceiling and nothing else: I rendered the same three instruments on the desktop leg with the cap forced to 64, and got the failing MicroPython digests back byte for byte.

instrument	desktop @14	MicroPython @14 (the stored digest)	either interpreter @64
farfisa	e23b4facfa530556	57645f34bd28d93b	be1eba7a4fcd61e1
minimoog	44d9926fd218b52c	f12729624852eed8	ae7734259e2b15a3
vox_continental	e4bbb90d6b078700	705dde35d9fea220	dc7ae0ac7c72f76b

Two things fall out of that table. The ceiling raise changed how these instruments sound — that is the concrete cost audioif#31 estimated and nobody had yet seen in the gate. And at 64 the two interpreters land on exactly the same bytes, where at 14 they disagree; the cross_interpreter_equal observation in these goldens is a 14-voice fact that inverts at 64.

What I am asking you not to do

Do not --capture-old these three, or the melodic MicroPython digests generally, to clear the red. The digests are doing their job: they noticed a sound change. Re-capturing them now would sign off the 14→64 raise for these instruments without your ear ever being in the room, and audioif#31 step 5 puts that squarely with you.

The honest state is that there is no correct golden to write for the MicroPython leg until the ceiling question is settled — one leg is pinned at 14 by the audioif release and the other floats with whatever the workspace binary was last built from.

Scope of what I measured

Three instruments, not all 53. All the melodic instruments that stack notes are candidates; the ten drum kits are not affected at any ceiling, which audioif#31 already measured. I did not run the private batches — --verify aborts here before reaching them, because micropython-vst3/soundtrack/Automata/instruments/ does not exist in this workspace.

Nothing captured, nothing committed, no golden touched.

[bdbarnett]

Brad's ear is in: he listened to the 14-vs-64 held-chord renders on 2026-09-06 and called 64 an improvement. The three MicroPython-leg digests this comment thread flagged are the correct sound; the stored 14-voice ones are the wrong one.

They are still not re-captured, and the reason is now mechanical rather than a pending listen: the CPython leg is pinned to audioif v0.2.0 at 14, so re-capturing the MicroPython leg alone would leave one golden file describing two ceilings. The effects program's Phase 1 moves AUDIOIF_PIN to the node commit (64) by git ref — Brad's word is that audioif is released once, at the end of that program — and at that pin move both legs render at 64 and agree byte for byte, as the table above already shows. Phase 1 re-captures exactly the comparisons the ceiling moved at that point, lists each one here, and cites audioif's docs/upstream-diff.md entry "The voice ceiling is 64, where CircuitPython builds 14" plus the listen. Until then the three MicroPython reds are understood and nobody runs --capture-old on them.

The 62 CPython-leg failures this issue was opened for are the accuracy program's and are not touched by that move; whatever the pin move does to them is recorded here verbatim, not captured.