Skip to content

Improvement: a stopped Octatrack is judged by the load it last played at (CPU FULL guard) - #1519

Draft
repeat98 wants to merge 2 commits into
mainfrom
improvement/cpu-guard-playing-load
Draft

repeat98 wants to merge 2 commits into
mainfrom
improvement/cpu-guard-playing-load

Conversation

@repeat98

Copy link
Copy Markdown
Owner
  • What was wrong or hard: The CPU FULL guard (Improvement: a busy Octatrack refuses a further module machine or effect with CPU FULL #1499, in Improvement: one Octatrack base update: update and sync screens, CPU FULL guard, stall frames, engine price in the package, Windows USB, a larger RAM boot stage #1502) reads the CPU meter at the moment of the pick. A stopped unit reads low, so picks made while stopped passed and left a Part that played over the line. On the owner's MKII (13 November 2026, twin 23f3f1b1 of base 4e9a87ea, 29 modules) the stopped unit read 70 %, four module effects were accepted, and playing then read 95 to 97 % with frames at 121 to 130 % until the DSP frames stopped (stall record 44). Measured with an encoder probe the same day, the panel is unchanged up to 83 %, and from 87 % a knob turn starts to wait for its redraw (0.1 to 0.2 s from 90 %).
  • What this changes:
    • While the unit is stopped, a pick of a module's machine or effect is judged by the meter's mean over the last four seconds the unit played, if that is more than the meter now (modwerk_status_cpu_load, cpu_note_played in status.c). The box then reads "WAS BUSY PLAYING" in place of "UNIT IS BUSY" and shows that figure.
    • Stock's machines and effects and NONE still always pass. Playing, nothing changes.
    • machine_registry.c asks the same figure for a machine pick. selection.c, dsp.c and manager.c are untouched.
    • Limits: the kept figure is replaced only by four seconds of playing, so a unit made lighter while stopped (a stock pick, a removed module, another project) refuses a module until it has played once. A unit that has not played since its start is judged as it stands. Installing a module is still never refused.
    • Not in this change: the base is not regenerated, so the base check fails until its turn at a regeneration.
  • How I checked it:
    • Host: test_status.c (kept only after eight readings in a row playing, a stop starts the count again, used only while stopped and only when higher, the refusal counted, stock and NONE pass, a lighter last play passes) and the registry host tests in sdk/tests/test_machine_events.py and test_fract_public_registry.py. A build with the new rule broken fails the new checks. node scripts/docs.mjs passes. npm run pr:ready was not run.
    • On a unit (owner's MKII, 13 November 2026, twin c6e655c7 of this branch, started from the flashed base; Air Chorus, Tape Echo, Euclid, Mini Verb, POLY8 and FM Synth 0.1.2 installed): never played, stopped at 54 %, Mini Verb on T1 FX2 went through. After twelve seconds playing at 93 %, stopped at 66 to 68 %: Mini Verb on T1 FX2, Euclid on T1 FX1 and POLY8 on T2 SRC were each refused with "CPU FULL / CPU 93% / WAS BUSY PLAYING"; FILTER and NONE on T2 FX1 went through. With FM Synth removed and no play since, Mini Verb was still refused; after twelve seconds playing at 81 % and a stop, it went through.
    • Not tried on the unit: a project load or a Part change between the play and the pick, a pick just under the line, the box over other pages.
  • Found on the way, not fixed here:
    • A RAM boot from one development twin into another never arrived: the screen stayed on BASE UPDATE / RESTARTING and the unit was gone from USB until a power cycle. The same image started from the flashed base came up. Cause open.
    • Frames ran past their time in every playing run with POLY8 installed (109 to 115 %, 124 to 126 % with FM Synth 0.1.2).
    • The diagnostics log held one cpu entry after four refusals; whether that is intended was not looked at.
  • What the guides lacked or got wrong, and where I fixed it: docs/MODULE_PERFORMANCE.md said the guard reads the moment of the pick; it now says how a stopped unit is judged and what the limits are. docs/verification/2026-11-13-cpu-guard-panel-lag.md is the record of the day's runs: what the guard refused and let through, the lag by load, how it was measured, and what was not shown. The UI tick count and tick gap did not show the lag at any load; the record says so.

Draft until: its turn at a base regeneration.

🤖 Generated with Claude Code

repeat98 and others added 2 commits November 13, 2026 13:29
The CPU FULL guard read the meter at the moment of the pick, so picks made
while stopped passed and left a Part that played over the line. Stopped, it
now goes by the mean of the last four seconds the unit played, if that is
more, and the box says WAS BUSY PLAYING. The base is not regenerated.

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
…he MKII

Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
@github-actions github-actions Bot added the enhancement New feature or request label Nov 13, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant