[Zac-Kyoti]

What

The first base PR from #1064. The beta base's key bus moves from Y $800-$9FF to Y $7E00-$7FFF, and Sidechain Compressor's MON words from Y $7F0-$7FF to Y $FF0-$FFF. That frees Y $7F0-$9FF on both cores for a DSP machine's voice, with no cost per access: both new places are internal memory.

• Y $7E00-$7FFF is the tail of the first internal FX2 slot (+$3E00). It is past every +$3DFD ring (Mini Verb, E-Verb) and stock's +$3DA2. Our standalone Sidechain and KYOTI builds have used it since 15 October.
• Y $FF0-$FFF is written by no stock effect. In the emulator, every stock effect went through FX1 and FX2 on all eight tracks, rotated, on both cores, for 902 frames. No non-zero write landed in Y $F00-$FFF or Y $7E00-$7FFF, and a watch on Y $FF8 saw no writer at all, zeros included.

Modules that move with it, as agreed in #1064:

Module	Version	Change
Sidechain Compressor	0.2.1	Manifest address tokens and declared ranges only; source Zac-Kyoti/octatrack-kyoti-fw 8868867
Sidechain Ringmod	0.2.1	The same-core read is add #>$7e00,a (ringsc.asm:187); package read claims at $7E00
BBD Delay	0.1.2	buffer_words=0x203A, as octabam since #783; reserved-Y resource 8,250 words

@npp1993 @JamCones: this is the change you agreed to on #1064. Please check your module's part before it merges.

How

Base

• dsp-sites.json, dsp_ledger.h and resident_dsp.resource_ranges: feature 1 (Sidechain) now owns three regions (MON $FF0+$10, the window, the bus $7E00+$200). Feature 8 (the key bus) owns the window and the bus at $7E00.
• One hidden assumption fixed: the board's reset_source hard-coded 528 (Sidechain's old first range), and the driver's @SPLIT@ allowed a single split. Both now stop a reset chunk at every region end from the ledger (dsp_sites.reset_ends, MW_DSP_RESET_END). The DSP receiver was already generic.
• buffer_fits and mw_hook_ranges_idle need no change. The table already makes them refuse a whole 16,384-word FX2 buffer on T1/T5 while Sidechain or the key bus is held, and admit a +$3DFD ring and BBD's 0x203A.
• Beta base regenerated (octatrack:base --beta --write, base 62ed0ec0). Analog BD's machine recipe was recaptured; only its imageSha256 moved, because the base's symbols shifted. The base-bound packages were rebound.
• Before regenerating, I checked that this toolchain rebuilds main's committed base byte for byte.

Modules and assets

• Packages and assets come from build-modules-isolated.sh (image sha256:2c78cdad…) at 1574c62e.
• USB packages: Sidechain Compressor fd275bf2, Sidechain Ringmod 91281f07, BBD Delay 58b77069 (the buffer field is now 8,250). Earlier versions' files are kept, as on main.
• Tape Echo's and Euclid's standalone recipes re-pin the rebuilt shared assets, as [tapeecho] Tape Echo issue of Volume Drop. #969 did.
• Composition proofs regenerated for the sidechain, sidechain-visible and analog-bd suites. The same selections build and refuse as before (169/512, 618/1,024, 146/212); only selections containing Sidechain Compressor changed.
• New pair: bbd+sidechain-compressor is no longer refused in card builds, because BBD's 8,250 words stay clear of Sidechain's key window.

Checked

Software

• module:verify, 0 mismatches of 162 selections each:
  • Sidechain Compressor: 62 images match, 100 matching refusals.
  • Sidechain Ringmod: 60 images match, 102 matching refusals.
  • BBD Delay: 64 images match, 98 matching refusals.
• test_resident_engines runs the base's resident engine in the DSP simulator at the new addresses. A cross-core key arrives exactly two blocks late for every enable order and core skew, as in 0.2.0. The test now pokes MON at $FF0.
• On Sidechain's native card image in the emulator, the tap writes Y $7E00-$7EFF on core 1 and Y $7F00-$7FFF on core 0, and nothing at Y $800-$9FF.
• Sidechain's native image of the module alone (fb7c5e31) differs from 0.2.0's (131142e1) in 12 bytes: the address words, six per DSP payload.

Hardware (my MKI, card builds, 30 October)

• Sidechain Compressor 0.2.1 alone (fb7c5e31, MW_SC021): same-core and cross-core keys duck; MON, KBAS and KWID behave; no other track appears in T1/T5 FX2 reverbs; project reload and a power cycle keep the settings.
• BBD Delay with Sidechain (c234d13c, MW_BBDSC): BBD on T1, T5 and T3 FX2 beside a keyed compressor, including maximum TIME, STGS 4096 and FRZ, is clean, and the compressor still ducks.

npm run check -- --base origin/main passes on this tree except one gate: Sidechain Ringmod 0.2.1 has no hardware qualification. The module reads the key bus only over USB, and I have no MKII. So its tests.qualification is still 0.2.0's, modules:generate refuses it, and module-documents.json is not regenerated here. With that one qualification field set locally to 0.2.1 (never committed), the whole check passes.

Finished on 10 November (owner's session)

Merge and regeneration. main (9b320991, 1,054 commits since f4e18fa4) merged in. The conflicts were all generated files. Base files were taken from main and rebuilt; the module asset JSONs were merged row by row, so each side keeps its own modules' rows.

• octatrack:base --beta --write: beta base dd3827f0126b3f76b8cbc63d754c401ba84605106166fac4737ae81f486043ec; the browser .bin equals build_core.py's (5a717aed…), stock-free and flash-safety scans pass.
• octatrack:module-packages -- --base-only: the five base-bound packages relinked; against e20e0bb4 only requiredBase moved (Sidechain 0.2.1 still fd275bf2).
• build-modules-isolated.sh at aaf3e5ca (image 1b15c3c0…, rebuilt from sdk/build/Dockerfile), imported with --development: only sourceCommit and the source fingerprint move.
• Tape Echo's and Euclid's standalone recipes re-pinned; Analog BD's proofs re-exported (212; no refusal flips; against main only the 28 selections with Sidechain Compressor change).
• Superseded packages (bbd/0.1.1, ring-sc/0.2.0, sidechain-compressor/0.2.0) removed, as modules:generate now requires.

Hardware: the owner's MKII, over USB, RAM-booted --dev twin 5015d2a7… of dd3827f0 (MAIN b0d74917…, never flashed). Measured from the unit's per-track USB audio, a kick on T1 as the key, folded on its onsets:

• Ring-SC 0.2.1 DUCK keyed from the other core (T5 from T1): -13 dB → -97 dB within 5-10 ms of each kick, back by 240 ms. From the same core on both cores (T2 FX2 from T1, T6 FX1 from T5): to -110 / -105 dB. KEY OFF: untouched. RING follows the kick (-84 dB between kicks, -14 dB on them).
• Beside BBD Delay 0.1.2 on T1 and T5 FX2 (the slot whose buffer tail the bus now uses) and Sidechain Compressor 0.2.1 keyed from T1: all admitted, the same-core and cross-core paths keep working, and the compressor ducks T6 6-12 dB more than self-keyed.
• Self-test with all three: passed (CPU 66.1 %, cores 54.1 / 50.2 %, longest frame 391 µs). Removal in use: refused (7). A 25 s trial rolled back by itself (Undo). npm run device:qualify with the three packages: passed (alone on T1/T5 FX2, four Ring-SC beside four BBD playing, 12/12 Part switches, 120 s soak, highest core peak 749 per mille, removal).
• Ring-SC's qualification, TESTING.md, hardware report and README filled from this run; module-documents.json regenerated.
• Not run: a power cycle (twin), parameter locks/LFOs on the module, eight instances a core, MKI.

Checks. npm run check -- --base origin/main passes (234 s). pr:ready's only remaining line is "changes a module and also the base": CI exempts pull requests opened before 9 November, and this one cannot be split, since Sidechain Compressor is a base input and the 0.2.0 modules read the old bus address.

Two small fixes found on the way (each with a test and a changelog entry):

• octatrack:module-packages refuses a package list that names a module twice (the merge had kept main's Sidechain 0.2.0 row; the run then died on "Use a new empty private controller package directory").
• device:qualify finds a chooser name whose words are in another order (RINGMOD SC for the SC Ringmod package); it failed to place Ring-SC before.

Guides

Three things a later developer would trip over; none is fixed here:

• dsp-sites.json reads as if a feature could own any number of regions, but the board and the driver assumed two (fixed here).

• standalone-recipes.json pins whole shared asset files, so any package rebuild forces a Tape Echo/Euclid recipe re-pin; [tapeecho] Tape Echo issue of Volume Drop. #969 did the same. A guide line in ADD_A_MODULE.md would help.

• octatrack-module-packages.py in write mode deletes every earlier version's .mwrm that main still carries. I restored those files by hand.

• Added (10 November): docs/DEVELOPER_WORKFLOW.md, "Make it mergeable": how to merge main into a branch that changes Octatrack base and package assets (take main's base files and rebuild; merge the module asset JSONs row by row, one row per module; then the rebuild sequence).

🤖 Generated with Claude Code

[repeat98]

Thanks Zac, this is a clean base change: reset ends from the ledger fix the two-region assumption properly, and npp1993's and JamCones's OKs on #1064 cover their modules' parts.

Three things before it can merge:

1. BBD's Sidechain flag. sdk/octabam/modules/bbd/octamod.module.json still lists sidechain-compressor in compatibility.conflicts, and bbd/README.md still says it isn't offered beside Sidechain Compressor. I added that flag in Fix: card builds refuse an effect whose FX2 buffer reaches Sidechain's key window #731 only because of the 16K claim, so please drop both. As it stands the configurator still refuses the pair, so BBD 0.1.2's release note wouldn't hold.
2. Ring-SC's release note. Ring-SC holds the key bus too, so while it's in use a full-slot FX2 effect on T1 or T5 is refused, as Sidechain's second line says. Please add a short line like that instead of "no change to how it works".
3. Order and the MKII run. Improvement: versioned Octatrack source-machine START callbacks #1029 and Improvement: a C runtime package can raise an event with no site (build.py --raise) #1059 also regenerate the beta base and go first. After that this needs main merged in and the base and packages regenerated once more, with npm run pr:ready until Ready; please hold off until I say they're in, so you only do it once. I'll then test that exact base on my MKII over USB (Ring-SC 0.2.1 keyed from the same and the other core, Sidechain 0.2.1 and BBD 0.1.2 on T1/T5 beside it, Keep/Undo and removal). With that you can fill Ring-SC's qualification and regenerate module-documents.json.

Separately: the packager deleting earlier versions' .mwrm files in write mode sounds like a bug of its own. Could you open an issue or a small Fix: PR for it?

---

Generated by Claude Code

[Zac-Kyoti]

Thanks, Jannik.

1. BBD's flag: dropped from compatibility.conflicts. The README now says BBD runs beside Sidechain Compressor since 0.1.2, and why (70e1d5a).
2. Ring-SC's release note: it now says that while it's in use, an FX2 effect on T1 or T5 that fills its whole delay buffer can't run there, and that every stock effect, Mini Verb, E-Verb and BBD Delay still fit.
3. Order: understood. I'll wait for your word that Improvement: versioned Octatrack source-machine START callbacks #1029 and Improvement: a C runtime package can raise an event with no site (build.py --raise) #1059 are in, then merge main, regenerate the base and packages once, and run pr:ready until Ready, ahead of your MKII run.
4. The packager: Fix: the Octatrack package rebuild keeps earlier versions' packages #1120. The wrapper now puts back every published .mwrm a write didn't rewrite, also when the run stops part way. On current main a full write run leaves the tree unchanged.

[repeat98]

Zac, #1029 and #1059 are in, and they regenerated the same base files, so now's the time: please merge main, regenerate the base and the packages once, and run npm run pr:ready until it says Ready. Then I'll run that exact base on my MKII as planned. Thanks for the BBD and Ring-SC fixes, and for #1120.

[Zac-Kyoti]

Thanks, Jannik. Done: main (f4e18fa4, with #1029, #1059 and #1120) is merged and the base and packages are regenerated once. Head e20e0bb4.

• The merge. The conflicts were only in generated base files (base-binding.json, controller-policies.json, the base .elemod and its fills, sources and variants). I took main's and regenerated over them. octatrack-module-packages.json keeps this branch's rows (Sidechain 0.2.1, Ring-SC 0.2.1, BBD 0.1.2 with its 8,250-word buffer).
• The base for your MKII run. octatrack:base --beta --write: default identity 672d9ffccc8771492b13d3076361920eb6e7fd79414de697b25ae3ad1a2379d9, private .bin 5e29d8f18d7d2cdba9d07efba9c8d274eb8c7d793e2f93c76e2615cc9824dddd. All seven USB layouts pass native/browser equality, and the browser .bin equals build_core.py's.
• Packages. Sidechain 0.2.1 (fd275bf2), Ring-SC 0.2.1 (91281f07) and BBD 0.1.2 (58b77069) are byte-identical to the previous push. Only Recorder Loop Fix's base-bound package was relinked, and the rest changed only their required base. octatrack:module-packages -- --check: every package identical.
• Isolated build. build-modules-isolated.sh from the committed tree compiles the same assets: sourceTreeSha256 is unchanged and only the sourceCommit labels differ. So I didn't re-import, and the standalone recipes and Analog BD proofs stay as they were.
• pr:ready. It stops only at modules:generate, on Ring-SC 0.2.1's qualification, which waits on your run as planned. With a local, uncommitted stand-in for that record, the full npm run check -- --base origin/main passes: app tests 2,768 passed, 1 skipped (340 files); SDK 502 passed, 22 skipped; recipes 39 passed, 1 skipped; lint, typecheck, bundle, catalogue, pairs, licences, changelogs and board all pass.

After your run I'll fill Ring-SC's qualification, regenerate module-documents.json and run pr:ready again.

[Zac-Kyoti]

Jannik, before I open the Phase 1 hook-slot base PR (it waits for #1098, since both regenerate the base), here is the design I prototyped, because it changes one answer in docs/OCTATRACK_PACKAGE_DSP_HOOKS.md (open question 3, "exclusive sites only, no chaining user yet"). BlackPyramids is that chaining user: it renders at the same per-track source site as Analog BD (site 5, dsp_track_source).

Why a chain, not a signature filter in the base. Analog BD checks each track's source record for its signature and returns to stock otherwise. BlackPyramids' engine has to see every track, not only its own: on a core's first track it ages its voice claim, and it frees the voice as soon as its own track's record turns stock. So the base can't pick one engine per track; each engine needs every call, in turn.

The chain. Site 5 becomes a chain site ("kind": "chain", "features": [4] in call order). The base's stub is:

• the site's dormant branch, to the replay (as today);
• one long bsr per member: dormant to a lone rts, and PLACE points it at that member's engine (the same one-word operand the receiver writes today);
• the replay of the displaced instruction, then rts to the stock source;
• an exit trampoline: move ssh,x0 and a branch to the stock exit.

An engine that returns (not its track) comes back to the stub, and the next member is called. One that renders drops its return and leaves through its exit, as Analog BD does now. The base aims that exit at the trampoline instead of the stock exit, so the trampoline drops the site's return too. The engines don't change: Analog BD's package is byte-identical, and only the exit word the base writes moves.

What stays as it is. A packaged feature's regions stay in the ledger, because the receiver's reset is built from them ("neither the host nor a module can name a DSP address"). So a new DSP machine still brings a ledger feature and a trust row in its own PR. Phase 2 (admission by declared entitlements) is where that would go away. Should packages declare their regions inside a base-named pool instead, say so and I'll look at it, but it loosens that receiver rule.

Checked so far, in the vendored DSP interpreter (not the chip):

• Analog BD through the chain on both cores, bit-identical to the same engine at the arena's top. Core B's render path runs out through the trampoline to the stock exit.
• A made-up second packaged member, a small engine that sees every call and renders only its own signature, beside Analog BD on both cores. Analog BD renders and the member is never called; the member renders after Analog BD returns; a stock track passes both and returns; a disabled member's call is skipped; a dormant site runs only the replay. On every path the system stack pointer ends where it started. A mutation (the trampoline without its move ssh,x0) fails exactly the render paths.
• Stock's stack depth at site 5: 0 on both cores (ot_emu PC watch at P:$39C / P:$1A2). An engine then starts at depth 2 of 16.

Found on the way. dsp_asm substitutes labels as text, so a label that is a prefix of another breaks assembly. The receiver's per-feature labels (hwchk1 and a later hwchk16, hwbase1/hwbase16) would have broken the first packaged feature past bit 8. Those labels now carry the feature at a fixed width, and each feature's reset cursor comes from receiver_reset instead of four fixed words in resident_base.patch.

Cost. The permanent block grows 6 words per core. A dormant member costs a bsr/rts pair per track per block. With Analog BD alone, a track it passes on costs three more instructions than today (the bsr, then the stub's replay and rts), and one it renders costs three more (the bsr and the trampoline's two).

Not done yet: the controller adapters are still Analog BD-named (base_bound.MACHINES, build.py --lease-policy, REQUIRED_CORES), and MW_ENGINE_FEATURES and the dev view are fixed at 4 features (a fifth one, BlackPyramids, widens them). Then a board-level test with a second packaged controller, docs, the changelog, the base regenerated once #1098 is in, and your MKII run of Analog BD on the new base.

Does the chain match what you meant by hook slots? If you'd rather have slots assigned at install (PLACE naming a slot index rather than a feature), that's a small change on top: the chain positions are already per member.

[repeat98]

Yes, the chain is what I meant by hook slots. Every engine sees each call in turn, Analog BD's package stays byte-identical, and the cost is a few instructions per track. Keep it per feature, as you prototyped, rather than slot indices assigned at install, and keep the ledger rule as it is. Phase 2 can revisit that. Go ahead with the hook-slot PR once this one is in.

For this PR, the next step is still my MKII run of its base. One heads-up: #1088 just merged and changed the Octatrack package assets, so expect one more main merge and regeneration before it goes in.

---

Generated by Claude Code

[Zac-Kyoti]

Thanks, Jannik. I'll leave this branch exactly as it is (head e20e0bb4, base 672d9ffc) until your MKII run, then merge main with #1088, regenerate once and run pr:ready. The hook-slot PR follows once this is in, per feature and with the ledger rule as it is.

[repeat98]

Zac, a change to the order. #1007 is in and rebuilt the beta base too. So that my MKII run covers the exact base that merges, I'll ask you to merge main and regenerate the base and packages right before my run, not after it. I'm away from my MKII for a few days and will ping you here when I'm back. After the run you fill Ring-SC's qualification and run pr:ready until it says Ready, as planned, and then #1195 follows.

---

Generated by Claude Code

[repeat98]

Zac, I'm back with the MKII and it's connected. To save a round trip I'll do the last step myself now: merge main into keybus-7e00, regenerate the base and packages once, run that exact base on the MKII (Ring-SC 0.2.1 keyed from the same and the other core, Sidechain 0.2.1 and BBD 0.1.2 on T1/T5 beside it, Keep/Undo and removal), then fill Ring-SC's qualification and run pr:ready. Please don't push to the branch meanwhile; I'll post the results here.

---

Generated by Claude Code

[repeat98]

Zac, done and pushed (f04fbaa1): main merged, beta base regenerated once (dd3827f0), packages relinked, assets rebuilt in the isolated image, recipes re-pinned and Analog BD's proofs re-exported. I ran that base on my MKII over USB as a dev twin and filled Ring-SC's qualification from it, so nothing is left for you on this branch.

Ring-SC 0.2.1 ducks from the same core (both cores) and from the other core, and RING follows the key; with BBD 0.1.2 on T1 and T5 FX2 and a keyed Sidechain 0.2.1 beside it, every path keeps working. Self-test, removal in use, a trial's rollback and device:qualify passed. Measurements are in the description and in ring-sc/evidence/hardware.md. npm run check passes; I'm watching CI now.

Two small tool fixes rode along (a duplicate package row is refused with a clear message, and device:qualify now finds RINGMOD SC). Once this is in, go ahead with the hook-slot PR.

---

Generated by Claude Code

[repeat98]

Merged and live, Zac. modwerk.app serves Sidechain Ringmod 0.2.1 (91281f07), Sidechain Compressor 0.2.1 (fd275bf2) and BBD Delay 0.1.2 (58b77069), byte-identical to this branch; main's beta base is dd3827f0, the base the MKII run covered (#1343's merge on top changed only module asset provenance and Analog BD's proof fingerprint, not the base). Thanks for the clean base work. The hook-slot PR can follow whenever you're ready.

---

Generated by Claude Code