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

@HISEnberg said in Third party node modulation output slot:

@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...

Interestingly, that last solution works for the node. But when I try to compile the network, the network won't compile. Not sure why yet. Need to look into it.

@Orvillain

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.

@Orvillain

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.

@Christoph-Hart Thank you!

@griffinboy
Thank you!! I'll take a look into it!

@Christoph-Hart said in Force mono node?:

Not sure I understand, where do you do the switch? And why do you want to switch if you know that a node is only processing a single channel?

If you're node is known to be mono, then just process the first channel in the implementation, or if you want to force a generic node to only process the first channel, you can use the wrap::fix template to force mono processing.

// instead of this member declaration MyClass obj; // use wrap::fix<1, MyClass> obj;

Your code is probably throwing an assertion at auto* right = block.getChannelPointer(1); if you have created the audio block from a single channel process data object.

I was thinking in situations where I want to do a tubescreamer emulation, for example. I don't want true stereo processing.

But maybe I'm overthinking it, and I just do a stereo node... collapse the channels... process the result... write the result back to output left and output right, with some gain compensation?

@HISEnberg Still can't seem to figure this out. I have an extra folder in my HISE project named External, which contains the bulk of my C++ code.

I've changed methods to adding this from FFTW3 directly into my project:

fftw3.h
libfftw3-3.lib
libfftw3-3.dll

And in my external C++ node I am doing something like this:

#define HAVE_FFTW 1 #define FFTW_DLL #pragma comment(lib, "../../External/libfftw3-3.lib")

But every time the compiler is failing to link:

!LINK : fatal error LNK1104: cannot open file '../../External/libfftw3-3.lib' [C:\Users\mikez\Desktop\HiseProjects\Personal\fftw-test\DspNetworks\Binaries\Builds\VisualStudio2022\fftw-test_DynamicLibrary.vcxproj]

@griffinboy Oh nice!! Some night time reading material right there!

@griffinboy ahhh thanks for clarifying! keep up the hacking i can tell youre on to something! 😀