Skip to content

audiograph: BIQUAD_RAMP sets how long a biquad walks to new coefficients - #378

Merged
bdbarnett merged 1 commit into
mainfrom
biquad-ramp
Nov 3, 2026
Merged

bdbarnett merged 1 commit into
mainfrom
biquad-ramp

Conversation

@bdbarnett

Copy link
Copy Markdown
Contributor

A graph biquad walks to new coefficients over about 20 ms, and a cutoff moved every block restarts the walk, so a fast filter sweep never catches up and sounds duller than the same sweep on synthio.Biquad, which steps at once.

audiograph.BIQUAD_RAMP is in ms, clamped to 0..1000, default 20. Frames are the nearest power of two, and 0 is one frame. It applies at the next move, and setting it isn't a move. A graph that doesn't set it is byte-identical to before: filter_f32_probe, move, frames, graph_parity, carry and source, plus poly106, poly6 and mono_one graph renders.

Tests: the four scoped unittest modules (265 tests), verify_graph.py --micropython --circuitpython agree, the five CI gates pass. A planted fault (the option ignored in biquad_ramp_shift) fails the new tests and verify_graph --fault ramp.

verify_dsp shows two cp11_fixes_probe differences by one sample at byte 676, the same on the unchanged base.

0 to 1000 ms, the nearest power of two frames, and 0 is one frame. The
default is the 20 ms every biquad has walked, and a graph that never sets
it renders the same bytes.
@bdbarnett
bdbarnett merged commit b7f6f32 into main Nov 3, 2026
34 checks passed
@bdbarnett
bdbarnett deleted the biquad-ramp branch November 3, 2026 02:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant