Since when Hise has an issue or crashes it doesn’t rewrite the memory, it will happen next time again and again. The same thing happens with the window configuration since it is saved only with a proper close without issues, recalling an old window configuration (this time without a warning like the audio interface one)

Instead, Hise should save the configuration (audio, midi, windows, etc) as they change and not when closing the app.

But usually for the interface if the configuration doesn’t change between Hise sessions the warning should just go away

I installed the latest version with the launcher btw

Build from source

convolution.gif

Now about the non-deterministic issue: if you compile that script it won't cause an error, as the JS compiler cannot know whether the variable setGlobalVariable is a function that can be called - it might get assigned to something callable at some point so it stays put and doesn't complain. However when you play a note, then it's time to call this variable and that's where HISE realises that you can't execute the (empty) variable.

This script will throw an error when you press the first note, but the first note off will then assign a function to the variable so subsequent notes will not raise the error but call the function. That example looks weird, but it's one of the more powerful features of JS (and HiseScript) to be able to reassign function slots to different functions like this so you can implement dynamic logic more easily.

Error:
duplicate symbol '_createDspObject' in:
duplicate symbol '_getModuleList' in:
duplicate symbol '_destroyDspObject' in:
ld: 20 duplicate symbols

Diagnosis:
Using nm on the compiled .o files, I confirmed these symbols are defined in THREE separate object files instead of one:

• Main.o
• include_hi_tools_01.o
• include_hi_tools_03.o

The function bodies live in HiseLibraryHeader.h, guarded by:
#if HI_EXPORT_DSP_LIBRARY
...
#endif

HI_EXPORT_DSP_LIBRARY is set to 1 in AppConfig.h (autogenerated from the .jucer's ), which is correct/intentional for exporting the DLL.

The problem: hi_tools_01.cpp and hi_tools_03.cpp both #include "../hi_dsp_library/hi_dsp_library.h" (confirmed via grep), which pulls in HiseLibraryHeader.h and re-generates the factory functions in those translation units as well — in addition to Main.cpp, which is the intended single exporter.

This seems like it shouldn't happen — hi_tools shouldn't normally depend on hi_dsp_library at all (dependency direction is usually reversed). Is this expected, or is this a bug in how the hi_tools amalgamation includes hi_dsp_library.h? Toggling IS_STATIC_DSP_LIBRARY in Projucer did not change the outcome.

Happy to share the exact grep/nm commands and full build log if helpful.

Dual SVG capabilities for buttons such as this.
(shown compiled in HISE)
DualSVGButtonWorkingExample.gif

Both import methods and settings panels are identical but are independent from each other between button states.

Screenshot 2026-07-05 at 9.10.52 PM.png

Screenshot 2026-07-05 at 9.14.27 PM.png

And If you didnt already know...
You can also do some pretty nice LED's with the app as well! 👍

Screenshot 2026-07-05 at 9.17.58 PM.png

Screenshot 2026-07-05 at 9.17.25 PM.png

Screenshot 2026-07-05 at 9.18.37 PM.png
They're available now in the preset menu.

I tried to load a 'duo-tone' svg with Base64SVG and this is the result?

Screenshot 2026-07-01 at 2.40.49 AM.png

SVG file:

Screenshot 2026-07-01 at 2.42.10 AM.png

Am I doing something wrong or not understanding something?

Heres the fix:

I don't have a "clean" example.
This is old code too, so not a good example of good c++ node practices or anything like that.

But here is a c++ node with a global cable(s) set up.

I've had no problems before, with updating existing c++ headers when adding more global cables.

If you make sure that the generated global cable code is up to date.
When you create more cables, you need to re-generate the global cable c++ code in Hise and update those parts in the c++

This generated stuff needs to be kept up to date with the cable names and IDs in your Hise project:

^ Here, only one global cable exists, however when you add more global cables to your Hise project, this code will need regenerating / updating with the new names and IDs of the cables in your Hise project.

C++ node example (using one global cable):

If its not an xml problem whats my next move?

If it was me I'd crack open a debugger and see what it says, not a simple thing to explain how to here though.

https://github.com/christophhart/HISE/pull/984

I can't believe the math were wrong the whole time
-> upDecayTime was inverted...

I've created my own little drag-and-drop implementation. Any suggestions for improvements?

Regarding the body + release in one sampler:
That's what I've tried first, but it's bugged when using together with loop regions.
It's what I described in this earlier post you commented on:
https://forum.hise.audio/topic/14799/loud-click-artifact-when-using-releasestart-with-looping-enabled/14?_=1781354181861

I haven't gotten around to testing it with 48kHz samples yet.
But by now I've found enough use cases to split apart the sections into dedicated samplers.