So this is actually the exact same crash report as a previous crash situation which has never really gone away. Occasionally and randomly happens when I'm moving the mouse across the UI / Sliders. Would love to get to the bottom of it! 😆

Please let me know if you have any insight @Christoph-Hart

hey did you ever figure out why this is happening i have ran into this issue too

@d-healey Fixed, thanks!

I'm new to HISE so I'm bound to do beginner mistakes lol

@HISEnberg said in Preset Browser - Show All Presets (ignore expansions):

I need to update the application/plugin each time.

Well according to the custom sample import tutorial project it's possible to load samples maps from a Base64 encoded string, so maybe that could help?

https://github.com/christophhart/hise_tutorial/tree/master/CustomSampleImport

@ustk I am testing whether rnbo in scriptFX can output midi to Hise to use for the UI display and modulation. At the moment Rnbo in Hise only allows one dedicated modulation output..
The patch above is Hise controller script sending cc messages to Rnbo Script FX, but then its being picked up by the Global Cable again, back to the Ui.

@Chazrox no i found out it is being caused by the synthesizer group idk why though

@d-healey Yah I'm assuming that must be the case. I'm going to try a fresh pull and build.

@ulrik said in Clone ScriptNode - getting a simpel value passed in...

Thanks Ulrik, how did I miss that?

LMP

@Christoph-Hart The plotter looks very rough... Are we able to get a better resolution?
It even looks like the resolution is not the only problem but the path construction itself... a stride value not optimised?

Screenshot 2025-11-10 at 13.37.27.png

@dannytaurus

Multiple wavetable synths will use a lot of memory.
Christoph's WT engine creates mipmaps (multiple antialiased copies of the wavetable).
If you have multiple WTs loaded into separate WT engines simultaneously, each one will have multiple copies of the wavetable.

However, this memory is probably still small compared to say, a regular multisampler... However 100 wavetables is gonna get big I can imagine you could pass the GB mark of ram usage.

Can't speak for cpu, you can try it but I'd assume cpu is okay as long as you don't have the inactive synths do any processing when silent.

If you are trying to acheive clickless swapping or something (idk if the WT engine does this already? Or what your goal is with having multiple WT engines - fast loading maybe??? No silence dropout???)
You could just have two WT engines, keep one silent, and use the silent one to load the new wavetable, once ready, volume fade between them. Then you get a seamless handover to a new engine.

@Taihongcraft But the node within a soft bypass node

@ustk aaahhhh here you go! haha. I gotta see this...brb.

@Rognvald You can put it all in the interface MIDI processor if you want to keep things simple - just avoid doing any UI stuff in the MIDI callbacks.

// This sort of thing should be avoided in a non-deferred script. Buttons[index].setValue(true); Buttons[index].changed();

However the ideal situation is you separate UI logic from MIDI processing by using separate processors for individual tasks.

You can add the velocity code I described above alongside your current script.

Those reg variables you have should most likely be const. Rule of thumb is if the values are fixed (or it's an array or object) use a const. If the value is going to be dynamic then use a reg.

@iamlamprey Looks like the value is being normalized somewhere.

@ustk
Thanks for your help. I set the AllowCompilation flag in the DSP Network’s properties, compiled the network, and exported the DLL. The effect now works — but I’m still getting the prompt:
“You don’t need to wrap the root node. Just tick the AllowCompilation flag in the properties, save this network and export the DLL.”

Do you know why the prompt keeps appearing even after I’ve done that?
I appreciate any guidance.
Thanks again!

Best,

Capture d'écran 2025-11-08 013223.png Capture d'écran 2025-11-08 014654.png Capture d'écran 2025-11-08 175324.png

@ustk Awesome! 😂

@Dan-Korneff Did the same, seems robust enough 👍

@ustk Thanks for the pointer. I added another commit other than the PR to ensure the new props are shown in the Data section of the UI.