HISE Filter Display Inconsistencies

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.

HISE | Docs

(docs.hise.dev)

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?

faustlibraries/filters.lib at master · grame-cncm/faustlibraries

The Faust libraries. Contribute to grame-cncm/faustlibraries development by creating an account on GitHub.

GitHub (github.com)

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

HISE | Docs

faustlibraries/filters.lib at master · grame-cncm/faustlibraries

55

1.7k

11.7k

102.1k