DSP Development Pipeline

[clumsybear]

I was thinking about a development pipeline and wanted to check if this would be possible.

Basically it's about extending HISE functionality.
I have programmed some DSP algorithms in Gen~ which at the moment are quite tricky to realise solely in HISE. I also managed to export them via JUCE as audio plugins.
The thing is, I really like to work within the HISE environment to do all the routing, mapping and audio design, especially since scriptnode showed up. Thanks for that @Christoph-Hart :)

So how complex would it be to port the JUCE code I wrote to HISE and use these DSP effects as Scriptnode nodes for example?

[d.healey]

Might help - https://docs.hise.audio/cpp_api/index.html#introduction

[Christoph Hart]

It should not be a huge task to write a wrapper for the Gen code using the script node API. There are a few issues though:

• the Gen code is using namespaces and global functions, which might be a bit annoying to manage (just looked at the example code in their Github repo and they create a global noise object which is a bit weird by today's coding standards).
• the license of the autogenerated Gen code is not permissive so you need to get a commercial license from Cycling74. Also I can't include the headers into the HISE codebase because they are not compatible with GPL.

The cleanest way would be to have a .dll containing the Gen code and a wrapper that loads the .dll. There is already a system in HISE that is pretty similar. I used it in a quite old project to load up a 3rd party FX library that wasn't available as source code.

http://hise.audio/dsp_api/

and an example project:

https://github.com/christophhart/HISE/tree/master/extras/script_module_template

It is not compatible with scriptnode yet (it used the pre-scriptnode scripting module system but updating it to the scriptnode API is trivial) and the example project needs to be modified to pick up the generated Gen code.

This way you could also load these nodes without having to recompile HISE, but you must ship another .dll along with your plugin and make sure that the user can load it (which is a really annoying process because I haven't found a good location on Windows that can be read and written to in all use cases).

[clumsybear]

@d-healey cheers man, it helps :)

you gave me a lot to think about @Christoph-Hart

I'm aware of the Cycling74 licensing situation. Also it's not it's not exactly ideal to have to ship an external dll along with the plugin.

So the simpler solution would be to rewrite all the code to SNEX, that way I can export as CustomNodes or could use the DSP in a simple JIT node in HISE, right?

[Christoph Hart]

Hmm, actually it would also be possible to create a static library that you can use in the compiled plugin, but this complicated the build process a little bit.

If you can rewrite it in SNEX, then obviously yes, that would be the best option (also SNEX is a 100% standard compliant subset of C++, so the conversion to a compiled node is pretty straightforward).