@griffinboy

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.

@griffinboy 195?! Release the kraken! haha 🔥 🔥

@Lindon

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.

Very cool man!

@Orvillain Nice work

@Allen Ah thanks for clarifying. I believe this should work the same for RNBO node as any other C++ node. You need to add these flags to your projects Extra Definitions:

NUM_HARDCODED_FX_MODS=4 //or however many slots you need NUM_HARDCODED_POLY_FX_MODS=4

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:

// number of modulation slots for Script FX HISE_NUM_SCRIPTNODE_FX_MODS=0 // number of modulation slots for Polyphonic Script FX HISE_NUM_POLYPHONIC_SCRIPTNODE_FX_MODS=0 // number of modulation slots for Scriptnode Synthesisers HISE_NUM_SCRIPTNODE_SYNTH_MODS=2 // If you plan to compile the DSP network to a C++ node // (which is possible with this node since HISE 5.0), you will // also need to set the corresponding preprocessor variables // for the hardcoded modules: // number of modulation slots for Hardcoded FX modules NUM_HARDCODED_FX_MODS=0 // number of modulation slots for Hardcoded Polyphonic FX NUM_HARDCODED_POLY_FX_MODS=0 // number of modulation slots for Hardcoded Synthesiser NUM_HARDCODED_SYNTH_MODS=2

@Christoph-Hart You are the best. I'll give this a try later on! Thank you as always.

@Alatar said in Audio Engine Sample Rate?:

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.

@Christoph-Hart PR sent, I'm not being precious about it so feel free to close again, good to get the practice in 😆

Coming right on time (well, when ready...) as I am to release a set of plugins based on the same engine so if fixes and updates can be done just once for the bundle I can already see the benefit of this!

@DanH said in RNBO Integration in HISE 4.1.0: Updated Workflow for Hardcoded-style DSP Networks?:

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

@Christoph-Hart

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

@clevername27 but 2 of the three reasons don't require a custom crash report (no crash => nothing to report. Running under debugger => even better diagnostics) and you're deliberately introducing the first reason with your custom crash handler :)

@tobitdsm There's quite a lot going on here which raises suspicion regarding your setup and workflow.

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.

@Lindon
Thanks will check them out.

#pragma once #include <JuceHeader.h> namespace project { using namespace juce; using namespace hise; using namespace scriptnode; using namespace snex; /** Smallest possible BPM listener example. Demonstrates: - TempoListener registration - tempoChanged() callback - BPM flowing into the audio graph */ struct MinimalBPMListener : public data::base, public hise::TempoListener { SNEX_NODE(MinimalBPMListener); struct MetadataClass { SN_NODE_ID("MinimalBPMListener"); }; static constexpr bool isModNode() { return true; } static constexpr bool isPolyphonic() { return false; } static constexpr bool hasTail() { return false; } static constexpr bool isSuspendedOnSilence() { return false; } static constexpr int getFixChannelAmount() { return 1; } // --- Tempo sync --- hise::DllBoundaryTempoSyncer* tempoSyncer = nullptr; double bpm = 120.0; // Exposed modulation value double lastOut = 120.0; // --- TempoListener --- void tempoChanged(double newTempo) override { bpm = newTempo; lastOut = bpm; // make it observable } // --- Lifecycle --- void prepare(PrepareSpecs specs) { if (tempoSyncer == nullptr && specs.voiceIndex != nullptr) { tempoSyncer = specs.voiceIndex->getTempoSyncer(); if (tempoSyncer != nullptr) tempoSyncer->registerItem(this); } // Initialize output lastOut = bpm; } void reset() {} ~MinimalBPMListener() override { if (tempoSyncer != nullptr) { tempoSyncer->deregisterItem(this); tempoSyncer = nullptr; } } // --- Processing --- template <typename T> void process(T& data) { static constexpr int NumChannels = getFixChannelAmount(); auto& fixData = data.template as<ProcessData<NumChannels>>(); auto fd = fixData.toFrameData(); while (fd.next()) fd.toSpan()[0] = (float)lastOut; } int handleModulation(double& value) { value = lastOut; return 1; } void setExternalData(const ExternalData&, int) {} }; }

This is a minimal example of how to get your custom C++ node to listen to the host BPM. Code above doesn't actually DO anything with the BPM information. But it proves the concept.

@David-Healey yes this is where I am arriving at. RNBO scriptnode with the xwax Timecode as the extra node.

And I assume these are the modulation colour references to use:

HiseModulationColours::ColourId::ExtraMod HiseModulationColours::ColourId::Midi HiseModulationColours::ColourId::Gain HiseModulationColours::ColourId::Pitch HiseModulationColours::ColourId::FX HiseModulationColours::ColourId::Wavetable HiseModulationColours::ColourId::Samplestart HiseModulationColours::ColourId::GroupFade HiseModulationColours::ColourId::GroupDetune HiseModulationColours::ColourId::GroupSpread

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 ????

modulation::ParameterMode::ScaleAdd modulation::ParameterMode::ScaleOnly modulation::ParameterMode::AddOnly modulation::ParameterMode::Pan modulation::ParameterMode::Disabled

@HISEnberg i tried. Still no sound - in my c++ node, do i have to define the midi input as well ?