High/Low Shelf Parametric EQ

[electrogear]

I can't find what is causing the glitching. Could I maybe put in a Min/Max somewhere so to prevent it distorting?

[theun]

Hi Mike,

I played a bit with your HPF [filter] coefficient calculator http://synthmaker.co.uk/forum/download/file.php?id=236 and MyCo's osm http://synthmaker.co.uk/forum/download/file.php?id=245 that integrates your coefficients into a bilinear filter.
(I didn't really look at the LPF variant, but what goes for the HPF also goes for the LPF, as long as the formula's are OK).

Like MyCo said, the green math is OK. The filter analysis tool made by bashert (it's in the WIKI) http://www.synthmaker.co.uk/dokuwiki/lib/exe/fetch.php?id=user_creations%3Aanalysis%3Abiquad_basics%3Abiquad_basics&cache=cache&media=user_creations:analysis:biquad_basics:biquad.zip shows the filter works fine, see the picture.

HPF.PNG (29.2 KiB) Viewed 1629 times

I cannot fully explain the stutter and plop effect when turning the Q and f0 knobs too fast, but my reasoning is as follows:

This type of filter (biquad IIR) is derived by mathematically transforming an (existing, proven) analogue filter into a digital filter.
[more exactly, by means of a z-transform the filter is transformed from the complex s-domain into the digital z-domain].
Theoretically this should result in a perfect representation of the original filter in the digital domain.
However when you take into account

• mathematical conditions (the usual such as linearity, continuity, ...boy, that seems long ago!) that may or may not be fully fulfilled
• approximations and/or simplifications used when performing the transform
• quantization error that is introduced using the filter in the z-domain

it seems apparant that the filter that's created probably will have some flaws. Some documented flaws of this type of filter are non-linear phase response and low-frequency sensitivity (below appr 250 Hz at 44.1 kHz sample rate).
And as this is a recursive filter once there goes something wrong (quantization errors, some kind of oscillation, ..) the result is fed back in the filter, making it worse.

I am not saying this type of filter is poor, on the contrary, this is a well known and well documented filter type, that is in many cases first choice. Moreover, the RB-J cookbook formula's compensate for some non-linearities. But I just try to give some explanation for what happens.

Part of the solution is indeed changing min max values, e.g. a min value for f0 that gives some improvement is 250 or 300 Hz (to be honest a cut off frequency of 0Hz doesn't make much sense), just change the min value in the knob.

Another part of the solution is to prevent users to turn the knobs too quickly, decoupling using dezippers doesn't seem to help enough. A solution with slew rate limiters forces that there is a maximum speed for changing the parameters and is rather effective.

slew rate.PNG (66.35 KiB) Viewed 1630 times

I must admit that even with both solutions implemented it still is possible to make the stuttering effect by quickly turning the knobs, anyway, there is a big improvement. I suppose further optimization is possible. Further, I suppose that there are more/other/different (partly) solutions, e.g. double precision for calculation of the coefficients.

Enough for today, I hope this helps you a bit further,

theun

[electrogear]

Hi theun. That shows a high shelf, not a nigh pass, I think you must have downloaded the wrong one. Thanks for the slew trick, I'll try it later!

Cheers,

Mike

[theun]

No, I didn't ......

It really is the HPF filter you made using green math calculations ...
Maybe you recognize it better this way:

filter curve.PNG (37.53 KiB) Viewed 1816 times

Different Q value, different curve ...

Here's the osm:

LPF HPF2. analysis.osm

(9.68 KiB) Downloaded 153 times

regards theun

[electrogear]

Ah yes, my apologies. I've tried the slew limit trick but it doesn't seem to make any difference for me. Still getting super-glitches that cut the sound, no matter how slowly or fast I move the controls...

[infuzion]

Ah yes, my apologies. I've tried the slew limit trick but it doesn't seem to make any difference for me. Still getting super-glitches that cut the sound, no matter how slowly or fast I move the controls...

I seem to remember having issues if one of the values hit 0.

[electrogear]

Yeah it does happen quite often on going from + > - and vice versa, but it also happens at other times too, not just with 0 crossing...

[theun]

Still getting super-glitches that cut the sound, no matter how slowly or fast I move the controls...

Strange, I didn't say there were no crackles left, but I think I really got it down for the bigger part ....
here's my osm ....

example-electrogear-HPF.osm

(159.14 KiB) Downloaded 135 times

Still getting super glitches ?

Anyway I've read and learned a lot about DSP filtering the last few weeks, I hope to come up with some other improvements next week or so.

[electrogear]

Ah... it wasn't the High Pass I was having trouble with, it was the high shelf... I'll do some more testing and get back to you later

Thanks for the help dude!

[MyCo]

The way, theun uses for smoothing the input is not very CPU friendly, because the green math is forced to recalculate 10 times per second.

I just found out, that not all problems are caused by division by zero. There is also another problem, there are 6 coeffs that are processed in green math, so let's say, the poly code starts when not all coeffs are calculated, then at least one coeff is wrong and may cause an unstable filter.

But there might be a way to smooth everything: use a hop inside the code, in this hop you load all coeffs into new variables, and the filter kernel uses the new coeff-variables instead of the real input coeffs.

[electrogear]

Aha... I will look into the 'hop' if I can find some info on it somewhere on the forum or wiki, and I'll give it a shot. Thanks for the tip!

Cheers,

Mike

[electrogear]

OK, please don't laugh if I've totally gone the wrong way about this, but this is what I gathered from your explanation:

Code: Select all

streamin in left;
streamin in right;
streamout out left;
streamout out right;

streamin a0;
streamin a1;
streamin a2;
streamin b0inv;
streamin b1;
streamin b2;
// mem
float y0,y1,y2,x0,x1,x2;
float y0b,y1b,y2b,x0b,x1b,x2b;
// coeffs
float a0b0,a1b0,a2b0,b1b0,b2b0;

//load coefficients into new variables
float a0z, a1z, a2z, b0invz, b1z, b2z;
hop(64){
a0z = a0;
a1z = a1;
a2z = a2;
b0invz = b0inv;
b1z = b1;
b2z = b2;
}

// /a0 optimisation
in left = in left + 0.0000000001;
in right = in right + 0.0000000001;

a0b0 = a0z*b0invz
a1b0 = a1z*b0invz;
a2b0 = a2z*b0invz;
b1b0 = b1z*b0invz;
b2b0 = b2z*b0invz;
x0 = in left;
x0b = in right;
y0 = a0b0*x0 + a1b0*x1 + a2b0*x2 - b1b0*y1 - b2b0*y2;
y0b = a0b0*x0b + a1b0*x1b + a2b0*x2b - b1b0*y1b - b2b0*y2b;
// push vars to mem
x2 = x1;
x1 = x0;
y2 = y1;
y1 = y0;

x2b = x1b;
x1b = x0b;
y2b = y1b;
y1b = y0b;
out left = y0;
out right = y0b;
in left = in left - 0.0000000001;
in right = in right - 0.0000000001;

This doesn't seem to give any better results. The EQ still works, but I'm still getting glitching - possibly even worse now. I've tried a few different values for the hop. This got me thinking, should I be interpolating the values now that we are giving it a new set of values every 64 (or whatever) samples?

Can you let me know if I'm on the right track, or if I'm being totally stupid?

Thanks,

Mike

[electrogear]

Just in case you are confused by the code, I have just made 6 new variables with the same names as the coefficients but with a 'z' on the end.

[MyCo]

well, the way is right. But you shouldn't use spaces in variable names. I didn't know that this even works, because there is no other programming language that can do that

[electrogear]

Spaces where? after/before the variable name? I do it in Javascript. Makes everything look neater and I find it easier to read. It ignores white space before/after a variable name - it only takes into account white space between characters within a variable name. Anyway, aside from me not knowing how to code properly, it doesn't seem to solve the problem. Should I be interpolating somewhere? Am I using the correct hop value?

Thanks,

Mike