[repeat98]

One Octatrack base update instead of six pull requests that each needed a base of their own (owner, 13 November 2026). New base: 4e9a87ea. Each part is merged with its commits and authors; the closed pull requests keep their own descriptions and test notes.

• What was wrong or hard:
  • A base update over USB showed almost no progress on the site, nothing said to leave the Octatrack alone, and the unit looked ready after its restart while the base was not saved yet (Improvement: the base update shows its progress and tells you to keep your hands off the Octatrack #1501).
  • On the unit the save showed a small box, a failed save left that box up until the next start, and a module sync showed nothing.
  • A busy Octatrack accepted a further module machine or effect and became sluggish (Improvement: a busy Octatrack refuses a further module machine or effect with CPU FULL #1499). A stall record did not keep the frames before it (Improvement: the Octatrack base keeps the frames before a stall #1494). A machine engine's DSP price lived outside its package (Improvement: a machine engine's DSP price lives in its own package #1487, by @twwwy). Some Windows PCs never claimed the Octatrack (Fix: Windows connects to the Octatrack where it never could (new USB revision) #1476).
  • The base had come within 668 bytes of the 1.25 MiB every base stages for a RAM boot, which is also a USB update's trial; a development build no longer fitted.
• What this changes:
  • Site: one blue progress bar for the whole update, a "Hands off your Octatrack" alert while it runs, a leaner view before it starts, and a saving step from the link. The sync dialog uses the same bar.
  • Base, status.c: a full-screen BASE UPDATE screen (RECEIVING NEW BASE, RESTARTING, WAITING FOR MODWERK, SAVING NEW BASE, BASE SAVED or NOT SAVED) that holds every key and knob from the first packet of a base until the write is over, and a MODWERK SYNC box with a bar. flash.c reports each own write's outcome and takes its progress down with it; ep0.c and boot.c say what the host is sending. Details in docs/OCTATRACK_TWO_SLOT_BASE.md, "Showing it on the Octatrack".
  • Base: the CPU FULL guard for machines and module effects (Improvement: a busy Octatrack refuses a further module machine or effect with CPU FULL #1499), the frames before a stall (Improvement: the Octatrack base keeps the frames before a stall #1494), the engine price in the package (Improvement: a machine engine's DSP price lives in its own package #1487), the new USB revision for Windows (Fix: Windows connects to the Octatrack where it never could (new USB revision) #1476).
  • Base: the RAM boot stage is 1.5 MiB (boot.h, boot.s). build_core.py still refuses a released base over 1.25 MiB, since units on older bases could not take it over USB, and prints the room left (1.7 to 3.8 KB on this base, by USB Audio layout).
  • diag.h: a UI tick comes 60 times a second, not every 2.7 frames.
  • Regenerated: the base and its variants, the five machine recipes (hash-only; Analog BD also its image hash), the controller rows, and the base-bound packages (Sidechain Compressor, Output Matrix, CC Map, Recorder Loop Fix, Analog BD).
  • Not in it: FM Synth 0.1.3 (FM Synth 0.1.3 (draft): cheaper on tracks that don't use it #1473). A module release does not ride in a base pull request; it follows as its own.
• How I checked it:
  • Host: test_status.c (the screens' texts and bars, the lock, a release only after its press, the give-up times, and the unit's sequence where the progress outlives the outcome for a moment), test_flash.c (outcome, progress down with it), the base's other host tests. Site: the dialog, sync, link and guide tests, tsc -b, eslint.
  • npm run pr:ready on this PC: every step passes except two SDK tests, test_dsp_packages_rebuild_from_source (KeyError 'modulation') and test_real_units_relocate_alike… (1004 != 1009), which the session behind Improvement: a busy Octatrack refuses a further module machine or effect with CPU FULL #1499 saw fail on untouched main on this PC as well. In CI both pass (module-suites sdk), and octatrack-source rebuilt the committed packages byte for byte.
  • On the owner's MKII, 13 November 2026, over USB with scripts/device.mjs (boot, then flash), the unit on two slots: five full updates between bases of this branch (be13282e, fb8ccf72, 71e143d2, 4e9a87ea), each saved and verified in 28 to 36 s; two starts from flash afterwards, each confirmed after 15 s with USB back on Windows. The owner watched the last full runs and said they worked well; I have no screen capture.
  • Found on the unit and fixed here: after BASE SAVED the screen could fall back to WAITING with the panel held for 20 s (the progress came down a moment after the outcome). Now covered by the host test.
  • Not checked on a unit: the site's dialog driving a real update (the runs used the command line), a module sync's box, a one-copy unit's conversion with these screens, a key held across the start of the lock, the guard on this exact base. The Improvement: a busy Octatrack refuses a further module machine or effect with CPU FULL #1499 notes on the guard, as its session wrote them:
    • On a unit (owner's MKII, 13 November 2026, development twins, 15 modules, playing at 126 BPM): on twin 0dbd0ee2, 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 (with 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 is not refused, by design.
    • Where the 85 % 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.
    • Measured and dropped (same unit, same day): a lower guard share does not help the panel (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 measured 76.4 % against 76.6 %, inside the noise, taken out again.
• Open findings from the unit, not fixed here:
  • Once, after a RAM boot from the USB-Audio-off variant to the standard layout, Windows said the device was not recognised until a power cycle; two repeats of the same step and two starts from flash worked. Cause open.
  • While the base saves itself and runs on, the load window showed one frame gap of 33 ms and a UI tick gap of about 3,600 frames (1.3 s).
  • WAITING FOR MODWERK does not say that it gives up by itself after 25 s.
  • The missing-modules page can open right after an update, since the update itself empties the modules.
  • A save sent one second after the restart was refused once ("hello was not confirmed") and went through eight seconds later; the site retries, the command line did not.
• What the guides lacked or got wrong, and where I fixed it: docs/OCTATRACK_TWO_SLOT_BASE.md described the old saving box and nothing about a lock or a sync box: rewritten there, with the unit checks still owed. The elekloader README said a RAM boot takes 1.25 MiB without saying that this is also the ceiling of every USB update: corrected there and in boot.h. The other guide edits come with Improvement: the Octatrack base keeps the frames before a stall #1494, Improvement: a busy Octatrack refuses a further module machine or effect with CPU FULL #1499 and Improvement: a machine engine's DSP price lives in its own package #1487 and are described in those.

🤖 Generated with Claude Code