stoneydsp / biquads Goto Github PK

Currently all Shelving Filter coefficients fall to the default settings and are detached from the GUI, meaning they are effectively blank entries.

The standard 2-pole shelving coefficient code is fairly convoluted and will likely require some new memory allocations purely for these filter selections, as a trade-off against bigger (and repeated) computations on each GUI update.

The 1-pole coeffs are much easier to implement, but there are two schools of thought on how these should work - one of which adheres to the "-3dB cutoff point" of the other 1-pole filters, and another that compensates the corner frequency as the "gain" slider is changed.

Possibly, both version of the 1-pole filter will be included separately. On the other hand, it might be better to map the gain compensation to the "resonance" control, thus offering compensated AND un-compensated shelves under a single entry.

As above.

Probably need to flip the sign of some coeffs...?

Current version: 1.0.4b

Currently, our plugin is fixed to only allow for stereo (essentially dual-mono) processing. While it would be nice to have an entirely flexible bus architecture to support as many channels as the client requests, this is not possible with the current code due to the OS scheme in place.

Our oversampling is initialized in our ProcessWrapper constructor to have 2 channels - a fixed (constant) integer value, with no means of changing this during run-time if desired. The supported busses layouts code has been chosen to reflect this hard-coded channel count, for now.

In order to have channel-extensible oversampling, we would need to have the correct build/initialize/reset mechanisms in place, likely driven by events coming from Audio Processor's "numChannelsChanged()".

The alternative is to restrict the plugin to pre-defined stereo (dual-mono) processing and reflect as such in the literature.

Current version: 1.0.04b

The typical BiQuad filter implementation is only safe within a range of it's frequency parameter - in our case, we have clamped the "frequency" parameter to min (SR/24576.0) and max (SR/2.125) ranges, and placed assertions if our parameter goes beyond the range of 20hz...20,000hz.

In our latest build, we have variable oversampling (up to x16) which can be used to combat the ill-effects of digital cramping (at the expense of heavy phase distortion, no less!) which affects the audio path only.

During testing and building, any increase in OS rate would be reflected in our filter's centre frequency shifting upwards by the same multiplicative amount as our selected OS setting. A quick and dirty fix is to apply our variable named "overSampling factor" to the frequency parameter by a division, before going into the biquad processor.

The above works just fine operationally - the correct centre frequency is returned by the filter output. However, we are able to crash via assertion if we move up to, say, x16 oversampling and bring our frequency down toward it's minimum position. The position is marked on the GUI as 20hz, but of course our division is causing the actual number to be changed inside our BiQuad processor - our hz value, as the BiQaud processor sees it, goes beyond the lower bounds of 20hz, causing the assertion.

The above quick and dirty fix has been substituted for a BiQuad processor-wide fix in which the "sampleRate" variable which is now made public, accessed via the Wrapper and multiplied by "overSampling factor" - which is all updated on parameter change - and this new SR, being processor-wide, is then propagated to the assertions as well as the parameter control. Everything makes sense again.

Making the sampleRate variable public is not really an ideal fix in the wider world - this variable shouldn't really be accessible outside by the user (or other processors), particularly at run time. It may indeed be possible to call the BiQuad's prepare() method each time the OS is changed, but this also will potentially incur much more run-time hassle than is needed.

A solid fix would leave the sampleRate variable private, similar to the juce DSP modules, but allow our filter's real centre frequency (and related safety assertions) to be oversampling-friendly.