Is this a basic MA filter?

[Derozer]

Hi folks...

which kind of filter is this in your opinion?
https://github.com/Geonkick-Synthesizer ... c/filter.h
https://github.com/Geonkick-Synthesizer ... c/filter.c

I just see two buffers and no coefficients at all on it (except factor for q):
https://github.com/Geonkick-Synthesizer ... ter.c#L276

basic Moving Average filter?

Never encountered it before

Thanks

[Urs]

It's a Chamberlin state variable filter.

I would have to look, but it seems to be pretty much 100% exactly the topology, just different variable names.

[Urs]

(the Q factor of up to 10.0 looks ginormous tho)

[Derozer]

It's a Chamberlin state variable filter.

I would have to look, but it seems to be pretty much 100% exactly the topology, just different variable names.

I know this Chamberlin version: https://www.musicdsp.org/en/latest/Filt ... rsion.html

But seems a little different? Here it uses 2 buffers (D1/D2) instead of 3 distinct buffer (for L/H/B).

Another implementation?

[Urs]

so this is the actual filter algorithm:

Code: Select all

h[n] = in_val - l[n - 1] - Q * b[n - 1];
b[n] = F * h[n] + b[n - 1];
l[n] = F * b[n] + l[n - 1];

Here, if h is saved or not has no effect on the equation - it gets replaced first thing and no h[n-1] term is used. Storing h is actually not important at all afaiaa. If it's stored for any reason, I can't see it from the filter code. Maybe there is, but by all means, above algorithm is a Chamberlin SVF

[Derozer]

so this is the actual filter algorithm:

Code: Select all

h[n] = in_val - l[n - 1] - Q * b[n - 1];
b[n] = F * h[n] + b[n - 1];
l[n] = F * b[n] + l[n - 1];

Here, if h is saved or not has no effect on the equation - it gets replaced first thing and no h[n-1] term is used. Storing h is actually not important at all afaiaa. If it's stored for any reason, I can't see it from the filter code. Maybe there is, but by all means, above algorithm is a Chamberlin SVF

Ok I'll give a try.

I've noticed that if the input signal goes above/below 1.0/-1.0f it introduces some weird glitches
But I'm not sure if its for some bugs or filter nature (for what I know this topology become unstable with higher freq, not higher level).

[mystran]

I've noticed that if the input signal goes above/below 1.0/-1.0f it introduces some weird glitches
But I'm not sure if its for some bugs or filter nature (for what I know this topology become unstable with higher freq, not higher level).

I don't immediately see any non-linearity in the code, so the most likely culprint for "weird glitches" is probably some other code failing to gracefully handle signals exceeding the available dynamic range (eg. conversion to integer format for actual playback would be a common candidate).

[Derozer]

I've noticed that if the input signal goes above/below 1.0/-1.0f it introduces some weird glitches
But I'm not sure if its for some bugs or filter nature (for what I know this topology become unstable with higher freq, not higher level).

I don't immediately see any non-linearity in the code, so the most likely culprint for "weird glitches" is probably some other code failing to gracefully handle signals exceeding the available dynamic range (eg. conversion to integer format for actual playback would be a common candidate).

Not sure: if I gain the signal with Filter Off, it just "hard clip". Instead, if I enable the Filter, I can see those glitch...

Note: from code, the hard clip seems after the filter.

[Z1202]

so this is the actual filter algorithm:

Code: Select all

h[n] = in_val - l[n - 1] - Q * b[n - 1];
b[n] = F * h[n] + b[n - 1];
l[n] = F * b[n] + l[n - 1];

Here, if h is saved or not has no effect on the equation - it gets replaced first thing and no h[n-1] term is used. Storing h is actually not important at all afaiaa. If it's stored for any reason, I can't see it from the filter code. Maybe there is, but by all means, above algorithm is a Chamberlin SVF

Actually, AFAIK, Chamberlin SVF is a combination of forward- and backward-Euler integrators, whereas this one is not. I think some people refer to both as Chamberlin, but the one here has, IIRC, a much worse frequency response than the Chamberlin's. To distinguish between the two I'm usually referring to this one as "naive", since it's implementing naive integration (off the top of my head I'm not sure if it's the same as backward-Euler) and "naive" feedback.

[Urs]

In my recollection this one has exactly the same code structure as the example in Chamberlin's book, but my memory might deceive me. I remember it to be HP response first, followed by BP/LP each with two multiplies with coefficients and added unit delays ("D1" and "D2").

I have the book in the office, I'll look it up if I don't forget.

(thinking about it, the distinction between states and unit delays might be what I've been missing and that's probably indeed the difference between this version and Chamberlin's, which has the extra steps of storing the delays at then end)

[Z1202]

E.g. here and here you can clearly see a different unit delay placement for the BP integrator. The code here also seems to suggest the same diagram on the first look.

[Urs]

Yep, indeed, I looked it up and memory deceived me.

[mystran]

I've noticed that if the input signal goes above/below 1.0/-1.0f it introduces some weird glitches
But I'm not sure if its for some bugs or filter nature (for what I know this topology become unstable with higher freq, not higher level).

I don't immediately see any non-linearity in the code, so the most likely culprint for "weird glitches" is probably some other code failing to gracefully handle signals exceeding the available dynamic range (eg. conversion to integer format for actual playback would be a common candidate).

Not sure: if I gain the signal with Filter Off, it just "hard clip". Instead, if I enable the Filter, I can see those glitch...

edit: I took a second look and noticed this at the top of the process function:

Code: Select all

        if (isnan(in_val) || in_val > 1.0f || in_val < -1.0f) {
                *out_val = 0.0f;
                return GEONKICK_ERROR;
        }

So if the input exceeds 0dBfs (or is NaN) then the filter just returns error instead of processing that sample at all.

[Derozer]

I've noticed that if the input signal goes above/below 1.0/-1.0f it introduces some weird glitches
But I'm not sure if its for some bugs or filter nature (for what I know this topology become unstable with higher freq, not higher level).

I don't immediately see any non-linearity in the code, so the most likely culprint for "weird glitches" is probably some other code failing to gracefully handle signals exceeding the available dynamic range (eg. conversion to integer format for actual playback would be a common candidate).

Not sure: if I gain the signal with Filter Off, it just "hard clip". Instead, if I enable the Filter, I can see those glitch...

edit: I took a second look and noticed this at the top of the process function:

Code: Select all

        if (isnan(in_val) || in_val > 1.0f || in_val < -1.0f) {
                *out_val = 0.0f;
                return GEONKICK_ERROR;
        }

So if the input exceeds 0dBfs (or is NaN) then the filter just returns error instead of processing that sample at all.

Yeah, I discover this right now without reading your comment hehe.

Yes, it's a sort of "clip" skipping some buffer value. Note that it returns error, but value the sample as 0.0f (i.e. *out_val = 0.0f), which is what used on return of the function.

So I think the "glitch" is because the filter doesn't process samples "in order"? A sort of clip+delay signal during filter...

Thanks

[gambero]

Yeah I'd say that's it. Muting any sample that's not between -1 and 1 (AND skipping to tick the filter) sounds a bit extreme to me but I guess there must be a reason (I would've just hardclipped and muted any NaN sample).