HISE Filter Display Inconsistencies

Christoph Hart

@ustk The whole topic of filter design is not really my strong suit, but the problem is that the visualization of a filter graph cannot be generalized and the current FilterDisplay expects a second order biquad IIRC algorithm and turns the five coefficients into a frequency / magnitude plot using some advanced math calculations that I don't understand. Hence my "ignorance" about subtle differences: either you live with those (slight) inconsistencies or you have to implement a custom visualization for each filter which will completely break the API.

I might be able to improve the "dummy" IIRC coefficient generation to match the filters better, but we're not achieving 100% mathematical accuracy for all filters with this.

Things like plugin doctor can just create a sine sweep and sample the response but that is not an option for the display that needs to update this with 60fps on real input.

I'm open to suggestions though as I know that you're a bit more in the topic. Adding the option for SNEX filter displays would currently require for you to calculate the IIRC coefficients yourself and pass them into a callback TBD.

aaronventure

@DanH said in HISE Filter Display Inconsistencies:

There's a dedicated Allpass filter node in scriptnode that works fine.

SVF allpass is fixed now but this one is still messed up. It's just like the filter version in my original post

It's not quite passing all the frequencies.

@DanH said in HISE Filter Display Inconsistencies:

I did recently discover that in scriptnode you can set multiple filters to the same external filter slot for your UI filter display tile, and that the filters will be summed graphically, so you can display steeper slopes if you cascade filters. This would also allow you to amend the Q values to more accurately display filter behaviour.

Valuable info, thank you. Documentation worthy for sure.

@Christoph-Hart said in HISE Filter Display Inconsistencies:

it's a rather drastic change of sound

How so? Here's a screenshot of a few filters 100Hz/3dB, 1000Hz/8dB, 5Khz LP.

On Pro-Q3, all Q values are at 1.0 for both the peaks and the LP.

First we see the default parametric eq with biquad filters. Peaks need Q=0.7071 to match up with the Pro-Q3 peaks at Q=1.0

Now here's the SVF parametric EQ. We can see it all match up nicely. Peaks still need Q=0.7071, but I also had to set the LP to Q=0.7071.

So they look pretty much the same. All you have to do, once you build the EQ with SVF, is make sure your low cut and high cut is set to 0.7071.

And here's your proof. I rendered an audio file with a random crazy EQ setting.

Bounced it, saved the project, rebuilt HISE with SVF, made sure the LP Q was 0.7071. Bounced that, inverted phase. There's definitely differences, but they're at -80dB. And I will bet you that's the harmonic distortion which comes with the biquads, which you can see in my post above. And the harmonic distortion increases with the number of filters, so in a scenario where you're using fewer than 10 and exporting 16bit, there's (figuratively) no difference at all.

I wouldn't call that a rather drastic change of sound.

Christoph Hart

@aaronventure nice detective work! It's still a delicate change because just telling people to change the Q of every filter they used so far is not a nice thing to do, but with your recent findings, the migration path might be even easier:

OK, so just to be sure:

svf_Q / sqrt(2) == eq_Q

so all it takes it the Q of the SVF_EQ to be multiplied with sqrt(2) to make the response identical? If that's the case, then the change can be made even easier:

enable HISE_USE_SVF_FOR_CURVE_EQ=1 by default for all build configurations or remove that codepath entirely as there is no real advantage of using the ol' filters.
add another preprocessor, HISE_COMPENSATE_SVF_Q_FACTOR which will be set to 1 in HISE and new projects and 0 for old compiled plugins. If that's active then it will just apply that factor before setting the Q. Do we want this to affect the parametric bands only or also the filter nodes in scriptnode?

As long as you have your sherlock Holmes magnifying glasses out, can you check if that Q factor is linear? So if you set the Q to 6.0 in the non SVF filter, it should sound the same as the SVF filter with a Q of 4.242?

aaronventure

@Christoph-Hart

It's even simpler than you think.

For the peak filters, the Q values are the same for the biquad and SVF version of the PEQ. the biquad PEQ LP/HP Q does nothing, there's no resonance control. But in order to match how the LP/HP biquad filters look in the PEQ, once you build the SVF PEQ, you need to set the LP and HP Q to 0.7071 or sqrt(2)/2, as the resonance control is now unlocked, i.e. SVF LP/HP have resonance control.

You can verify this right now in scriptnode using the svf_eq (NOT the svf ) node vs the biquad node, regardless of how you build the PEQ.

svf biquad.gif

I'm unsure whether your preproc will be worth much, because the PEQ Q control was still available for the low pass and high pass filters, even though it did nothing. So if they tweaked it at all, once they build the new commit with default SVF EQ, even if they build with that preproccesor flag that compensates, they'll still hear the difference.

But if that compensation affects the SVF LP/HP in general, it'll fuck with the one in scriptnode, too.

I think you're overthinking it, it's just for the Parametric EQ. The svf_eq node is fine (the svf node is fucked just like the Filter module). Your commit tag or however you choose to communicate this should say something like "Parametric EQ is now SVF by default. Enjoy zipperless automation and distortion free equalisation with Q-unlocked LP/HP. If you want to maintain the previous response of LP/HP in your parametric EQ, set the Q to 0.7071 (previously it did nothing).

Here's another one which confirms that the Q for biquad peaks is the same as the Q for SVF peaks. Again, you can go do this in scriptnode right now and do a null test. Shelves are the same. Same phase response, too.

ustk

@Christoph-Hart said in HISE Filter Display Inconsistencies:

the problem is that the visualization of a filter graph cannot be generalized

Yeah I was expecting this answer unfortunately...

Things like plugin doctor can just create a sine sweep and sample the response but that is not an option for the display that needs to update this with 60fps on real input.

Sure it's not a comparison that can be made. a tool that analyses a signal spends most of the cycles doing so, while it's not a job for an audio plugin which needs to just show the (approximated) transfer curve

I'm open to suggestions though as I know that you're a bit more in the topic. Adding the option for SNEX filter displays would currently require for you to calculate the IIRC coefficients yourself and pass them into a callback TBD.

That would be a great thing indeed! But I wouldn't say I'm more in the topic, even if definitely interested, I lack advanced mathematics since I much preferred playing guitar than going to the math class! Anyway I'm on that track so having a way to use the computed coeffs out of a SNEX node would be amazing

Christoph Hart

@ustk I'm currently toying around with a new way of handling this - basically it keeps the old behaviour of approximating the graph with IIR coefficients for all the two pole filter types, but you can override it with a custom function that can calculate any filter response.

// Return the magnitude (or phase) value for the given frequency
double getPlotValue(bool getMagnitude, double normedXAxis)
{
    return someValue;
}

If the filter type overrides that function it will prefer this for calculating the plot. Now with my limited filter knowledge I figured out how to write the transfer function for the one pole filter and the result is promising:

but to figure out the transfer function for the other filter types (ladder, moog, etc) would require me to actually understand this paper lol...

aaronventure

@Christoph-Hart what does chatgpt say?

Christoph Hart

@aaronventure tried it already got only gibberish…

Christoph Hart

@Christoph-Hart I got it working without the Q for the ladder filter but now I‘m stuck.

aaronventure

@Christoph-Hart sorry, what is normed x axis? You're passing in the frequency and then you're taking the return somewhere down the line and doing the log scaling?

ustk

@aaronventure I think normedXAxis means a 0-1 linear value for freq (log), to be confirmed...

@Christoph-Hart Zavalishin's VA paper, aka THE paper...
I got a grasp on VA filters from some DSP popularising books. Now, to understand the original paper is a whole different story

Lindon

@Christoph-Hart said in HISE Filter Display Inconsistencies:

but to figure out the transfer function for the other filter types (ladder, moog, etc) would require me to actually understand this paper lol...

Yeah that things a nightmare _ i've tried a bunch of times, and struggle to get past the first section....

Christoph Hart

Alright, I've pushed the new filter graph API and also added support for creating custom filter curves using a SNEX node! You can now create your custom filters and then add a function to your SNEX class

double getPlotValue(int getMagnitude, double fNorm)
{ 
    return 1.0f; // calculate the filter response here
}

I've added a example to the snippet browser that implements the one pole filter including the filter graph creation entirely in SNEX.

https://docs.hise.dev/tutorials/scriptnode/index.html#snex-one-pole-filter

Let me know if you hit any issues. Maybe now that we've levelled the playing field and anybody can create those filter graphs, we can tackle the ladder filter response together...

aaronventure

@Christoph-Hart said in HISE Filter Display Inconsistencies:

we can tackle the ladder filter response together...

Maybe you can find some clues here?

https://github.com/grame-cncm/faustlibraries/blob/master/filters.lib

The ladder filter (as well as the filters.ladder node) currently in HISE is somewhat busted:

Frequency parameter only does something until 7k, past that it does nothing
Q only works from 0.6 to 8.0

Dan Korneff

@Christoph-Hart I could probably help with this. I'm calculating transfer functions all day

ustk

@aaronventure May I ask if you're building Hise in a specific manner to get it to work as an FX plugin, essentially with PluginDoctor?

This is something I did a lot in the past but now the plugin is not recognised (AU & VST3). Tried in Live and PluginDoctor. I'm out of solutions...

aaronventure

@ustk

HISE_BACKEND_AS_FX=1

But you have to load Metaplugin in the doctor, and in there you should load the VST3i of HISE built with this flag, as Metaplugin will let you plug audio in into a plugin like a proper host.

ustk

@aaronventure

~~Mmmm... I have this flag but it still doesn't work...~~

~~So you mean [PD] <= [MetaPlug as FX] <= [Hise as Instrument] ?~~

EDDIT: it seems to work, I had an error message but Hise seems to launch

HISE Filter Display Inconsistencies

22

1.8k

10.4k

90.8k