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! 😀

@Christoph-Hart You move quick! Glad I mentioned it, my HISE-senses were tingling when I heard about this project. :)

Are you considering integrating the klang toolchain for rapid C++ deployment inside Scriptnode? I've been trying to find faster methods like this.

On another tangent which I don't think anyone else here cares about except for me, is the introduction of MIDI 2.0 to the JUCE Framework. Obviously this will take a bit of time, as there really aren't any major devices on the market that even support this yet, but it would be good to keep an eye on this development and possible integration into HISE in the future!!!!

@Orvillain
3d59f862-0879-4207-8770-9f6729fd3a8b-image.png

huh... well I got SOMETHING in there...

This is just chatGPT chod, but it has given me the above. The issue is... it doesn't update immediately, I have to switch the selected display buffer in the node using the external icon button.

// ==================================| Third Party Node Template |================================== #pragma once #include <JuceHeader.h> namespace project { using namespace juce; using namespace hise; using namespace scriptnode; // ==========================| The node class with all required callbacks |========================== template <int NV> struct LoadAudio: public data::base, public data::display_buffer_base<true> { // Metadata Definitions ------------------------------------------------------------------------ SNEX_NODE(LoadAudio); struct MetadataClass { SN_NODE_ID("LoadAudio"); }; // set to true if you want this node to have a modulation dragger static constexpr bool isModNode() { return false; }; static constexpr bool isPolyphonic() { return NV > 1; }; // set to true if your node produces a tail static constexpr bool hasTail() { return false; }; // set to true if your doesn't generate sound from silence and can be suspended when the input signal is silent static constexpr bool isSuspendedOnSilence() { return false; }; // Undefine this method if you want a dynamic channel count static constexpr int getFixChannelAmount() { return 2; }; // Define the amount and types of external data slots you want to use static constexpr int NumTables = 0; static constexpr int NumSliderPacks = 0; static constexpr int NumAudioFiles = 1; static constexpr int NumFilters = 0; static constexpr int NumDisplayBuffers = 1; AudioBuffer<float> originalBuffer; int originalSampleRate; int originalNumSamples; bool bufferNeedsUpdate = false; // Scriptnode Callbacks ------------------------------------------------------------------------ void prepare(PrepareSpecs specs) override { display_buffer_base<true>::prepare(specs); if (rb != nullptr) { rb->setActive(true); if (bufferNeedsUpdate && originalBuffer.getNumChannels() > 0) { updateBuffer(originalBuffer.getReadPointer(0), originalNumSamples); bufferNeedsUpdate = false; } } } void reset() { } void handleHiseEvent(HiseEvent& e) { } template <typename T> void process(T& data) { static constexpr int NumChannels = getFixChannelAmount(); // Cast the dynamic channel data to a fixed channel amount auto& fixData = data.template as<ProcessData<NumChannels>>(); // Create a FrameProcessor object auto fd = fixData.toFrameData(); while(fd.next()) { // Forward to frame processing processFrame(fd.toSpan()); } } template <typename T> void processFrame(T& data) { } int handleModulation(double& value) { return 0; } void setExternalData(const ExternalData& data, int index) override { display_buffer_base<true>::setExternalData(data, index); if (data.isNotEmpty()) { originalBuffer = data.toAudioSampleBuffer(); originalSampleRate = data.sampleRate; originalNumSamples = originalBuffer.getNumSamples(); bufferNeedsUpdate = true; // ✅ delay actual update } } // Parameter Functions ------------------------------------------------------------------------- template <int P> void setParameter(double v) { if (P == 0) { // This will be executed for MyParameter (see below) jassertfalse; } } void createParameters(ParameterDataList& data) { { // Create a parameter like this parameter::data p("MyParameter", { 0.0, 1.0 }); // The template parameter (<0>) will be forwarded to setParameter<P>() registerCallback<0>(p); p.setDefaultValue(0.5); data.add(std::move(p)); } } }; }

@Christoph-Hart I wondered about using an audiofile as well, seems a nice solution especially if I am creating the curve in the script interface.

But a global cable seems promising too, I need to wrap my head around the data type it can send. Just sending the control points and creating the curve in C++ node is surely a more efficient solution...

Thank you guys! Lot of stuff to look into here! Appreciate the help. Will report back!

@njAudio03 There also exists a convolution “reverb” module in HISE already. This probably doesnt address the your design/project objectives directly but studying it’s integration in the HISE source code (along with the FFT it relies on), along with @griffinboy External C++ primer should get you started.

@Lurch Cheers dude! I'll check it out!

So until we have native Cmajor support in HISE, how much of a pain would it be to compile a Cmajor patch as C++ and then use it in HISE as a 3rd party C++ node? Is there a web of dependent libraries you'll have to worry about including?