Crossover Equalizer - Glitch on transients

[zonkmachine]

The Crossover Equalizer could use some interpolation. It's riddled with glitches on suddenly increased values of the crossover frequency knobs. Interestingly the glitches seem only to be present on increase and not decrease of the knob value.
crossoverequalizerglitch.mmp.zip

See earlier issue #3339 and its fix #3343

[PaulBatchelor]

@zonkmachine best way to do that is with a 1-pole smoothing filter. If there isn't a class for this, one should exist (I can make this)

[michaelgregorius]

Here you can find some code for a smoothing filter:
http://www.musicdsp.org/archive.php?classid=3#257

[PhysSong]

For example, Calf Filter has a control called "Intertia" for that purpose.
https://calf-studio-gear.org/doc/Filter.html

[PaulBatchelor]

The code for sp_port can be used as a smoothing filter:

https:/PaulBatchelor/Soundpipe/blob/master/modules/port.c

The frequency knob value is read at the beginning of a render block (a control-rate signal), then passed into the smoothing filter as an input signal. The smoothing filter works inside the render block at audio rate.

"inertia" is the smoothing amount. Usually this is represented as a tau coefficient, which can be roughly thought of as smoothing time. In sp_port this is the htime variable.

[PaulBatchelor]

Did some digging.

The crossover EQ filter is made up of a few instances of StereoLinkWitzRiley filters, which is a basic filter type used all over LMMS. It only calculates things on a per-sample basis, and there is no support for block-rate parameter smoothing.

It actually turns out in the same file where the StereoLinkWitzRiley filters are defined (BasicFilters, there is also perfectly suitable code for a onepole smoother. I would build a class on top of this called ParameterSmoother or something that elegantly handles the parameter updates and block-rate to audio-rate signal conversion + smoothing.

The way to update LinkWitzRiley filter is with the setLowpass and setHighpass methods. This would need to be called at audio-rate any time the audio-rate output from ParameterSmoother changes. There should definitely be audio-rate parameter caching of some sort so that these methods don't get called every time... it looks like the filter does a full bilinear transform in order to calculate the coefficients.