Filter Overhaul

[m-m-adams]

The existing deluge filters have a fixed configuration of a low pass ladder filter into a high pass ladder filter. The goal of this issue is to switch it to something more like the hydrasynth, where the LPF would have a variety of models to choose from and the HPF is replaced by an SVF that's continuously variable from LP to band or notch to HP. This opens up a ton of possibilities for sound design by

Main goals:

• [x] Augment HPF ladder filter with a morphable (low-band/notch-high) SVF. Maintain a classic switch to use the existing HPF
• [x] Enable series/parallel switching of the two filters
• [ ] Enable oscillator routing separately into each filter not feasible without overhauling oscillators
• [x] Add additional filter types to LPF slot (SVF, vocal, BPF bank, maybe more)

Side goals:

• [x] Refactor filter code to separate ladder filter code from filter configuration #304
• [x] Refactor filter menu and configuration code so that a single list of filters can be maintained and automatically populate menus and configuration (mostly)

I'm transferring the progress tracker from my PR to this issue so that PRs can be incorporated when usable before the entire issue is complete.

[m-m-adams]

PR #103 adds a lowpass SVF to the low pass filters, accessible through the existing filter selection button

[bfredl]

The goal of this issue is to switch it to something more like the hydrasynth,

While I like the filters on the hydra and agree it is a good inspiration, I wonder if it not be simpler for us and more flexible to treat the two filter slots as symmetric and allow to pick any filter model in either slot?

The hydra has a static voice count and a fixed DSP budget per filter, while the deluge is dynamic and more complex voices vs more polyphony is a tradeoff which is exposed to the user.

[m-m-adams]

Yeah that's a great point, I was mostly thinking about what the UI would look like. If the HPF slot is always an SVF then the HPF db/oct pad can become the morph control

On the other hand there are the two unused pads below the current filter controls that we could expand too, but I think that would need a broader discussion on how we're handling UI changes

[sichtbeton]

Edit : has been resolved.

As already stated on the discord, there is a strange behaviour when using the filter for a complete kit. steps to replicate the bug:

• have one item or more in a kit
• enable "affect all"
• turn lpf to "svf"
• play a longer sound to hear the filter actually working
• turn the filter down.

what happens is that the moment the filter is engaged, there is an audible click coming from the filter and there is a very sudden jump in cutoff.

[m-m-adams]

I'm currently looking at building a filter interface with three methods, init, setup and filter, plus a name

• Init - construct a new filter with cleared internal state
• Setup - take in cutoff, resonance, drive/morph, return gain compensation, configure filter parameters
• filter - run filter on a buffer and keep internal state
• name - string for display

HPF and LPF filters will be separated. Init will be called when the filter type is changed in the UI routine, and all filter type checks in the audio engine can be skipped as it just calls setup and filter on the currently initialized filter.

The filter selection code will be updated to iterate through a list of possible filters, initialize the selected filter, and display the result of its name method. This will allow new filters to be built by simply implementing the three methods and adding to the filter list.

I have a couple possible thoughts on UI:

• HPF is always an SVF with db/Oct morphing between low/notch/high, LPF UI unchanged; or
• The currently empty pad below db/Oct controls drive (which could be treated as morph where it makes sense). Db/oct can then iterate through the HPF/lpf filters respectively

[sapphire-arches]

That sounds good to me architecturally. A single indirect branch per window per filter should be no problem. For those of us with less filter know-how, will switching to an SVF impact the sound of the hpf, or can the default setup remain exactly equivalent?

On Sat, Jul 1, 2023, 09:17 Mark Adams @.***> wrote:

I'm currently looking at building a filter interface with three methods, init, setup and filter.

• Init - construct a new filter with cleared internal state
• Setup - take in cutoff, resonance, drive/morph, return gain compensation, configure filter parameters
• filter - run filter on a buffer and keep internal state
• name - return a string for display

HPF and LPF filters will be separated. Init will be called when the filter type is changed in the UI routine, and all filter type checks in the audio engine can be skipped as it just calls setup and filter on the currently initialized filter.

The filter selection code will be updated to iterate through a list of possible filters, initialize the selected filter, and display the result of its name method. This will allow new filters to be built by simply implementing the three methods and adding to the filter list.

I have a couple possible thoughts on UI:

• HPF is always an SVF with db/Oct morphing between low/notch/high, LPF UI unchanged; or
• The currently empty pad below db/Oct controls drive (which could be treated as morph where it makes sense). Db/oct can then iterate through the HPF/lpf filters respectively

— Reply to this email directly, view it on GitHub https://github.com/SynthstromAudible/DelugeFirmware/issues/105#issuecomment-1615979044, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALRZ7EUXYSGIFSYJR3YGUDXOBESNANCNFSM6AAAAAAZTIRTWA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[sichtbeton]

Having a routing mechanism to send either both oscillators to one filter or having two separate filters in varying order would be nice.

Maybe (as you already stated) using the two unused pads below hp and lp for this? So for each osc would have these states:

1) filters off 2) filter 1 3) filter 2 4) filter 1 + 2 5) filter 2 + 1

The left pad would be for osc 1 and the right for osc 2.

The drive knob could be the one above (from left 10/ from top 3) that currently only says "SOON".

[sichtbeton]

this could be closed also because there are a couple of PRs already?

[m-m-adams]

largely implemented by #336, one remaining