feat(core): name every preset node, and add a multi-band EQ over existing filters

[vanceingalls]

Every preset node is named for the job it does — "Remove Rumble", not highpass. A chain that cuts mud and then lifts clarity must not show the same name twice.

INVARIANT: any new HfAudioFxNode field must be added to BOTH parseAudioFxChain AND serializeAudioFxChain.

Not hypothetical — the first commit added fromPreset to the type and the writer but not the parser, so the tag was silently dropped on every reload and a preset could no longer find its own nodes. The round-trip test passed the whole time because it compared only node types.

Tone (EQ) is built as a composite over existing filters rather than a new effect type: users know what an EQ is, they don't know they want five peaking filters — and the registry's params are flat key/value and cannot express a band array.

🤖 Generated with Claude Code

[miga-heygen]

Review: feat(core): name every preset node, and add a multi-band EQ — #3178

Verdict: LGTM

This is the fix half of the #3177+#3178 load-bearing pair, and it delivers. All three new HfAudioFxNode fields round-trip correctly:

• Parse side (defensive): typeof node.X === "string" && node.X — guards against non-string JSON values, drops empty strings.
• Serialize side (trusted): node.X ? { X: node.X } : {} — the typed interface guarantees string-or-undefined, so truthiness is sufficient.

Both sides agree on the empty-string boundary (both treat it as absent). The pattern mirrors the existing fromCarve handling exactly.

The upgraded round-trip test is the real deliverable. The old test compared only n.type; the new one compares { type, id, fromPreset, label }. The PR body's comment — "Comparing only types is what let fromPreset be silently dropped by the parser" — is exactly right, and the new test is the regression gate.

Named-job labels flow through node.label ?? def.label in the UI — no hardcoded label map. The "names every node for the job it is doing" test enforces this across the entire preset catalog, with a thoughtful exemption for stacked pairs (consecutive identical nodes with matching params = one stage built from two biquads, like steep()).

EQ composite is well-designed. fromEq tagging follows the fromCarve pattern. Per-band ids are minted with the chain visible, so automation lanes address the correct biquad. readAudioEqBands reads from chain nodes (source of truth), not a cached list. The round-trip test verifies audioEqIds, band names, and gain values all survive serialization.

One observation (non-blocking): setAudioEqBandGain identifies bands by node.label === bandName. If custom bands with duplicate names were passed to addAudioEq, the fader would move both simultaneously. Not exploitable today (preset band names are unique), but a doc note making this explicit would be good hygiene.

No blocking issues.

---

Review by Miga

🤖 Generated with Claude Code

[github-actions]

Fallow audit report

Found 4 findings.

Duplication (2)

Severity	Rule	Location	Description
minor	fallow/code-duplication	packages/core/src/audioFxEq.test.ts:33	Code clone group 1 (7 lines, 2 instances)
minor	fallow/code-duplication	packages/core/src/audioFxPresets.test.ts:208	Code clone group 1 (7 lines, 2 instances)

Health (2)

Severity	Rule	Location	Description
major	fallow/high-crap-score	packages/core/src/audioFx.ts:874	'nodes' has CRAP score 63.6 (threshold: 30.0, cyclomatic 15)
critical	fallow/high-crap-score	packages/studio/src/components/editor/propertyPanelFxSection.tsx:269	'FxCarveModule' has CRAP score 148.4 (threshold: 30.0, cyclomatic 24)

Generated by fallow.