External C++ Node file management
-
Has anyone developed a good method for organizing and structuring your external C++ nodes (the same might apply for Scriptnode Networks, faust files, RNBO, etc.).
I'm trying to package a set of C++ nodes I've created for easy distribution but the operation is very cumbersome. Currently I need to create all of my headers inside the ThirdParty folder, and any attempt at adding subfolders here will cause the compiler to miss the nodes contained therein.
As a side note, does anyone here wrap C++ nodes inside of Scriptnode? I am finding that with the new updates to HISE I need to manually resave my Scriptnode Network every time I recompile my FX.
-
I just make sure everything has a unique node name using version numbers.
My c++ nodes all use multiple header files.
I have headers for various DSP and utilities, and the c++ nodes simply include and use those. The node files themselves have practically no DSP inside.The utilities are programmed using namespaces and templating. There is never any conflict and so it's not difficult to include lots of different nodes into one project
Another idea is to have unique sub folders for these header files.
The actual node itself can't go into a sub folder. But the extra headers you include in that node can.
If you want good separation you can have a unique subfolder for the implementations of each node.
Now you can copy paste nodes and their helpers without worrying about conflict or shared names. -
@griffinboy Thanks for your input!
I have a similar system right now with some main headers that do the heavy lifting DSP, and my "node files" simply reference the namespace and attach the parameters! Seems to be the best method currently.
Really I am trying to think of a way for distribution for other HISE users, as I will have 50+ nodes with no subdivision/categorization other than the naming of the file. It isn't the worst, but I would hate to make users create 50+ third party nodes, run the compiler, and then replace those nodes with the proper headers. I am trying to think of a way around this issue so it is clear for new users what is going on and the integration is as seamless as possible.
I'm starting to consider ways of compiling HISE with external packages as well. Say for example there was a Griffinboy pacakge that could be intgrated via ProJucer, then you can compile HISE and this package will be available already in Scriptnode. It might save time vis-a-vis having to recompile every external node you are using, but the obvious limitation is you couldn't edit your node afterwards....
-
Christoph mentioned that he might look into a c++ sharing system if there was enough demand for it (we already have the snippet browser)
It's true that importing c++ nodes into a Hise project is not resistance free.
I think the main issue is the autogenerated json files and c++ files that get created / edited when you use the 'create 3rd party c++ node template'If those files could update and correct themselves automatically, then importing existing c++ nodes into a new project could be done simply by copying the code files into the thirdpartynetworks folder and compiling.
-
@griffinboy This is true. Is it really just a matter of adjusting the
node_properties.jsonthat makes the difference for simple user importing here? Given we can share scriptnode .xml via the HISE snippet system, I could hypothetically see it working with external C++ nodes in that case.Alternatively, I plan to just setup a HISE-project on Github, so I believe it will be easy enough for users to import the nodes from here (All they will need is the DspNetworks/ThirdParty folder and grab the headers and node_properties.json).
As a gross tangent I was catching up on API 2025 and one project, Klang Studio, really caught my attention:
https://www.youtube.com/watch?v=VIj--bcosas
https://nash.audio/klang/rapide/Full disclosure, I haven't tried this out yet, but the idea of having an IDE operating inside of the plugin seemed pretty clever for quick prototyping and debugging. I know it's quite simple to run HISE from the debugger and basically do the same, but it gave me some interesting ideas about the directions Scriptnode could take (i.e., working on C++ nodes similar to how we can work on Faust nodes already).
All that being said, these all seem like topics that really only interest you, me, and a handful of other users here!
-
@HISEnberg wow, thanks for the heads up, this looks awesome. I was toying around a bit with the underlying klang framework and wrote some lightweight wrappers to load them as scriptnode nodes.
It's basically the same idea that I had with SNEX, but I chose to write a complete JIT compiler from scratch instead of using the clang toolchain. Now if I would do it again I would definitely go this route too.
-
@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!!!!
