4-5 Multi Band Limiters

[tw350]

Request preparation

• I used an AI assistant to help structure this request
• I checked for existing issues covering the same feature

What would you like?

This would put the DAW into the pro range. Multiband AGC along with it would be really sweet. A 4 or 5 band limiter would be nice in itself. If possible.
Thanks Jerry KE9U

[aethersdr-agent]

Thanks Jerry. Triage analysis follows — flagging for maintainer scope decision before any implementation.

Where this would fit

The TX audio chain today (in order, all wired through AudioEngine):
ClientGate → ClientEq → ClientComp → ClientDeEss → ClientTube → ClientPudu → ClientReverb → ClientFinalLimiter

Relevant single-band pieces already in place:

• src/core/ClientComp.{h,cpp} — feed-forward compressor with a built-in brickwall limiter; stereo-linked detection driven by max(|L|,|R|); version-counter atomics for lock-free UI→audio param publish.
• src/core/ClientFinalLimiter.{h,cpp} — tail-stage brickwall peak limiter, also single-band, with DC-block + post-trim and meters (gainReductionDb, limiterActivityPct, pre-limiter clip count).

A grep for crossover, Linkwitz, multiband, band-split across src/ returns no matches — there is no existing multiband DSP scaffolding to extend, so this is a from-scratch addition rather than an enhancement of an existing block.

What a 4–5 band limiter would require

1. Crossover filter bank — Linkwitz-Riley 4th-order IIR (cascaded biquads) is the conventional choice for limiter/AGC band-splits because the magnitude responses sum flat at the crossover points. For 4 bands that's 3 LR4 crossover points; for 5 bands, 4. Standard voice-band breakpoints would be something like 250 / 700 / 1800 / 3500 Hz at the 24 kHz TX sample rate the chain runs at.
2. Per-band limiter — one ClientFinalLimiter-style feed-forward peak limiter per band, with independent threshold / release. Attack on a multiband limiter is typically pinned (~1–2 ms) because the perceptual benefit comes from independent release ballistics per band, not per-band attack tuning.
3. Recombination — straight sum of the band outputs. LR4 sums to allpass at crossovers, so phase coherence between bands is preserved as long as each band path has identical group delay (i.e. each band's limiter must share identical lookahead — or all be zero-lookahead like the current ClientFinalLimiter).
4. UI — a new applet alongside ClientCompApplet / ClientCompEditor, with per-band threshold/release/GR meters and a crossover-points display. ChannelStripPresets persistence + MIDI mapping wiring.
5. Multiband AGC — Jerry mentions this as a "would also be nice." Mechanically it's the same crossover bank feeding per-band leveler/compressors with longer time constants (program-dependent rather than peak ballistics). Sharing the crossover with the limiter would be ideal — implies the architecture should split the filter bank into a reusable component from day one.

Scope questions for maintainer

• Placement. Replace ClientFinalLimiter with the multiband, or insert before it (multiband upstream, single-band brickwall still at the tail as a safety net)? The second is safer — the multiband becomes an opt-in tone-shaping stage and the existing safety guarantee stays intact.
• 4 vs 5 bands. 4 is the broadcast/SSB convention (low / low-mid / high-mid / high). 5 adds a dedicated "presence" or "air" band. For a voice-bandwidth (0–3 kHz typical, up to 4 kHz with Aetherial Tube Pre-Amp extended TX BW) chain at fs=24 kHz, 4 is probably the sweet spot — 5 starts crowding bands into 500 Hz wide slots.
• Crossover topology. LR4 IIR is the standard, but a FIR/FFT-based linear-phase split would avoid the IIR group-delay smear and is realistic given the chain already tolerates the tail-stage ClientFinalLimiter. LR4 is cheaper and matches the existing biquad coding patterns in ClientEq.
• Bundling. Treat multiband limiter and multiband AGC as one issue or split? They share 80% of the code (the crossover bank), so one PR is probably more efficient than two — but separate issues let the maintainer authorize them independently.

Handoff summary

• Known: No existing multiband infrastructure; single-band limiter + comp are in src/core/ClientComp.{h,cpp} and src/core/ClientFinalLimiter.{h,cpp}; threading model (atomics + version counter, lock-free UI→audio) is well-established and the new block should follow it.
• To fix / build: New ClientMultibandLimiter (and optionally ClientMultibandAgc) in src/core/, plus crossover-bank helper, plus UI applet + ChannelStripPresets serialization + AudioEngine wiring at the chosen position in the chain.
• Why this needs maintainer review: Scope (4 vs 5 bands), placement relative to ClientFinalLimiter, crossover topology (IIR vs linear-phase), and whether multiband AGC is in-scope for the same PR — all need a call before implementation.

[tw350]

This would probably only useful to a few, maybe. Multi band compression or limiters let the user control targeted areas to control dynamics etc.. Where a general overall compressor affects the whole mix. I'm good with the way it is, it was just a thought.