BLOCK_SIZE_BITS can be chosen at compile time - #1152
Conversation
amy.h defined the block size unconditionally -- 256, or 128 under AMY_DAISY -- so a host could not ask for anything else without editing the header. tulip5 wants 128 and 64 on the ESP32-P4 for lower latency (the P4's CPU is thought to have the headroom; the S3's does not), and its only route was a patched shadow of amy/src. Now `-DAMY_BLOCK_SIZE=128` is honoured: the default sits behind `#ifndef`, BLOCK_SIZE_BITS is derived from it, and a size that is not a power of two from 32 to 1024 is an #error. Built with nothing passed, the result is byte-identical to before -- 256, and 128 on Daisy. BLOCK_SIZE_BITS is derived as an expression rather than one literal per size on purpose: `make amy/constants.py` greps every numeric #define out of this header and the last one would win, so a ladder of literals would have reported BLOCK_SIZE_BITS=10 to Python and the generated JS. The expression is skipped by that grep and the two literals above it still report the default. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
I lean towards have AMY_BLOCK_SIZE_BITS as the thing that can be overridden, and Having the human specify in terms of bits underlines the constraint that block size must be a power of 2. This is (probably) needed for fast indexing. (Should check the uses of |
|
Good point. Let me try that instead |
dpwe's review: a host should choose the block in BITS, with the size (1 << BLOCK_SIZE_BITS), because asking in bits is what says the block has to be a power of two. Checked against the code and it does: every use of BLOCK_SIZE_BITS is a shift -- the per-block amplitude ramps in oscillators.c and the pan ramp in amy.c -- so a block that was not a power of two would ramp to the wrong place with no error. So -DBLOCK_SIZE_BITS=7 is the override, 5..10 is #error'd outside, and AMY_BLOCK_SIZE is (1 << BLOCK_SIZE_BITS). Built with nothing passed it is 8 (256), or 7 (128) on Daisy, as before. The special case is amy/constants.py: it is a grep of the NUMERIC #defines in amy.h, so a derived AMY_BLOCK_SIZE dropped out of it and with it out of amy.render() and the generated JS API. The Makefile rule now appends AMY_BLOCK_SIZE computed from the BLOCK_SIZE_BITS that landed; constants.py and amy_api.generated.js are regenerated (the JS diff is the one key moving to the end). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Done! |
🎛️ AMY HW CI (AMYboard bench)Flashed this PR's AMY (LoadTestChord: 6-voice Juno ✅ PASS — the bench ran the test to completion.
Full chord settled render μs: 2822 (was 2822, Δ +0.0%) (peak 2826, 39 samples) ⬇️ Artifacts: serial log · load trace · report Self-hosted bench (amyboardci). FAIL means only that the test could not run — the load values are informational, with no threshold and no audio compare. See |
bwhitman
changed the title
⛓️ tulipcc integration PR openedThis merge was pinned into tulipcc for full-system CI: shorepine/tulipcc#1348 Test it there and merge that PR to move tulipcc onto this AMY. |
2 participants
amy.h defined the block size unconditionally -- 256, or 128 under AMY_DAISY -- so a host could not ask for anything else without editing the header.
Now
-DBLOCK_SIZE_BITS=5is honoured: the default sits behind#ifndef, AMY_BLOCK_SIZE is derived from it, and a size that is not a power of two from 32 to 1024 is an #error. Built with nothing passed, the result is byte-identical to before -- 256, and 128 on Daisy.