I realized that these plots are a little misleading.

The VCS3 filter is highly nonlinear and "bubbles" and so taking a measurement of frequency response is quite difficult since the filter is moving around on it's own accord all the time...!

Here is a more detailed FFT that shows how the filters do match more closely than the graphics in my paper would suggest.

.

Black is the slow accurate VCS3, Red is my optimized VCS3.
Not oversampled.

c4000_fb9_m42__one3_c050_k2.png
c10000_fb9_m42__one3_c050_k2.png
c2000_fb6_m42__one3_c050_k2.png
c10000_fb9_m42__one3_c050_k2.png

When oversampled, I found the proposed model to be perceptually close to the slower accurate model. The resonance and cutoff and gain values differ slightly, but the important aspects of the filter are retained.

Yeah thats another way to do it!
Basically the same idea.

Except like you noted, the Hise filters (which I think are ports of the stock Juce ones?) are primitive, they cramp in the high end of the spectrum (the filter shape get warped near nyquist). And so that's not very nice to see on the graphs.

Plus, the trouble with analog style filters (if they are actually simulating the hardware topology) is that the cutoff frequency on the knob won't actually line up with the frequency in the real filter, the cutoff frequency on the graph won't really match the real frequency the filter is at internally.

It is possibly you may need to first add that to HISE's extra pre processor definitions in projucer first and recompile HISE, then also add those to your project (so it works in the compiled plugin).

The documentation about this is a bit hard to find. There's also a forum post about it here.

Here is a spreadsheet of the different HISE flags you can use (it needs to merge this into the documentation somewhere).

Just for some extra context this is straight from the docs:

Is HISE using an internal sample rate, which is different from the host sample rate?

Hise plugins run at the DAW sample rate.

The Hise app itself runs at the sample rate you choose in the settings.

Resampling may occur somewhere else on your PC, but Hise is trying to match whatever it's told.

@voxuer1 so I'm on RNBO 1.4.2 and everything works fine

Thanks
I'll hold off for a bit then,
until you've finished that!

First the workflow in that video is a touch out dated, but I believe for all intents and purposes it should work. Just create the C++ node, write your code then Compile the DSP networks as DLL. From there you can load the C++ node in an FX Slot or inside of Scriptnode and attach the parameters to your UI.

Secondly, do any HISE based plugins work for you inside of Reaper or any other DAW? Say for example if you attach your one knob to a gain node, does it function properly? It could have something to do with your setup.

Third, easiest way to have someone help you debug this would be to share the C++ script or a very minimal version of it. This way someone here could rebuild the plugin on their end and test it.

Fourth point you can disregard if you feel like it, but FFT is a pretty complex topic. An external C++ is definitely the way to go but I would recommend starting with something simpler if you are just beginning.

Last point is to make sure to get rid of the old plugin binary versions in your VST3/AU folder. Use Export>Clean build directory before compiling the plugin in order to clear your build folder. Also maybe try changing the plugin code in the project settings.

Is there any limitations around which colour a particular parameter should use? Or is it really just down to how you want it to appear in the module tree??

And for the ParameterModes, would it be these ????

@ustk nice I basically setup the same system but just using HISE’s version of get/setLatencyInSamples. I’m assuming you are using the JUCE version of this in the C++ node? I believe HISEs API is exactly the same but I could be wrong.

Well my use case is different, I just compute my inner DSP latency for dry/mix situation in a split node, not reporting the whole latency of my project to the DAW...

Regarding what @Christoph-Hart and @griffinboy are saying, could oversampling help here?
Despite the fact it'll eat up some more CPU, of course...

Voices in Hise are managed 'automatically'.
Take a read of Polydata.

I don't remember where it can be found. But the Hise source has all the .h and .cpp files which have the implementations for voice handling. You can see what's currently going on, and perhaps there will be some useful api that you're not yet making use of.

Christoph is the person to ask though!

Is there a way to update the scriptnode UI with the relevant new parameter

Not without hacks. The best way of thinking about this is a black box communication of parameters into the node. Now if you want to update a UI state that you display on the plugin interface, global cables (and their data callback) are the way to go, there you can easily pack everything up into a nice JSON and send it back to HISE Script (on a deferred thread!), but I wouldn't recommend going the extra mile of updating the internal scriptnode parameters only so that you can look at them in the network with the right value.

Oh yeah I tried a moog. It was arguably not very good haha.
It becomes very dark in a very musty way.

Unless you're willing to stack a few to get a high order it's going to sound quite blurry. Whether or not that's a bad thing is up to you.

For refrence the real antialising filters from pedals like the memory man are steep. They are almost like low order elliptic lowpasses. That's the closest 'standard' filter response I found to the real thing. This allows them to have a high and crisp feeling cut-off (3.5k) while still killing aliasing.
It's different to a synth filter.

But that's what the hardware BBD effects do anyway.