[repeat98]

• What was wrong or hard: With many modules installed the panel turns sluggish. The CPU budget only prices machine renders; modules' hooks, effects' control code, a DSP voice's glue and a USB recording are outside it, and the frame guard can only drop machine renders. On the owner's MKII (12 November 2026, base 926a4fdf, 20 modules) the CPU meter stood at 76 % stopped and 85 to 95 % playing, and nothing refused anything.
• What this changes:
  • A pick of a module's machine or effect is refused with the CPU FULL box while the CPU meter stands at 85 % or more over its last four seconds (mw_cpu_hot, modwerk_status_cpu_recent). The box shows the measured load and "UNIT IS BUSY". The same machine on its own track, stock's machines and effects, and NONE are never refused, so a busy unit can always be made lighter. The refusal counts in the diagnostics log as a CPU refusal.
  • docs/MODULE_PERFORMANCE.md says where the 85 % line comes from, and that the panel is to be judged by the CPU meter, not by the frame guard's share.
  • The effect check sits in the loader's selection guard (selection.c, through build_core.py's refusal edits), before stock writes the pick, and asks modwerk_status_effect_busy. selection.c links after the write-lease entries: on twins of main and of this branch modwerk_controller_write_begin/end are at the same addresses and the first moved symbol is past them, so Analog BD's reviewed recipe should hold. dsp.c and manager.c are untouched.
  • Not in this change: the base is not regenerated: octatrack-base.test.ts fails on the stale base until its turn in the base queue.
• How I checked it:
  • Host: test_machine_registry.c (refused at the line, passes one under it, own track and stock never refused, counted, no price box) and test_status.c (the meter's mean, the box's fields; a module effect refused on its slot and counted, a stock effect, NONE and a load under the line pass). npm run check passed except the stale-base test above, run before the effect commit and not again after it. npm run sdk:check fails two tests that fail the same way on untouched main on this computer (test_dsp_packages_rebuild_from_source: KeyError 'modulation'; test_real_units_relocate_alike…: 1004 != 1009).
  • On a unit (owner's MKII, 13 November 2026, development twin 0dbd0ee2 of this branch, 15 modules, playing at 126 BPM): at 86 % CPU, picking FM Synth on T2 in SRC SETUP showed "CPU FULL / T2 SRC / FM SYNTH / CPU 86% / UNIT IS BUSY" and T2 kept its machine. On twin 865bcc10 (this branch with main merged, Fix: an installed Sidechain keeps its key bus memory free from the start, so picks are not refused NO ROOM after a restart #1492 in): at 85 % picking Euclid on T2 FX1 showed "CPU FULL / T2 FX1 / EUCLID / CPU 85% / UNIT IS BUSY" and the slot stayed NONE; at 88 % FILTER and NONE on the same slot went through; stopped, at 63 %, Euclid went through. Not tried on the unit: a pick just under the line, the box over other pages, a waiting (queued) pick, a Part change or paste that brings module effects in (those are not refused by design).
  • Where the line comes from: 32 units' uploaded load windows, 30 October to 13 November 2026 (2,053 five-minute windows). At 85 % mean CPU or more the longest UI tick gap passed 100 ms in more than half the windows; under 65 % in about one in twenty.
• What was measured and dropped on the way (same unit, same day):
  • A lower guard share does not help: with FM Synth 0.1.2 installed, a share of 50 % skipped over 20,000 renders a second and the load stayed at 77 %.
  • Two small cuts in the guard's wrapper (one timer read fewer, one battery-RAM read fewer) measured 76.4 % against 76.6 %: inside the noise, taken out again.
  • By module, frame interrupt share playing: FM Synth 0.1.2 +13 (5 of it the base's wrapper from Fix: FM Synth's voices pass the Octatrack base's frame guard and CPU budget #1483, 5.5 its own code), Tape Echo +6.7 in use, Euclid about +3 in use, Repitch +2.9; ten others nothing.
• What the guides lacked or got wrong, and where I fixed it: diag.h says a UI tick comes every 2.7 frames; on the unit it is 60 a second (300 in 5 s), which first led me to a wrong conclusion. Not corrected here, since diag.h is a base source; it belongs with the base rebuild. docs/MODULE_PERFORMANCE.md now says to judge the panel by the CPU meter.

Draft until: its turn in the base queue (rebuild after #1494 and #1487).

🤖 Generated with Claude Code

[repeat98]

Closed into #1502: all changes that need a new Octatrack base go out as one base update. This branch is merged there with its commits, and its description and test notes are carried over.