Custom third party C++ methods...

[ustk]

@Christoph-Hart This might be (and probably is) a dumb question.

After seing the benefit added by third party C++ nodes, I can't help thinking about something similar for custom added script API.
Sometimes script algorithms can be CPU expensive, slowing down considerably the thread.

In the past, I added my own methods for deporting heavy script functions into C++, but this requires to recompile Hise and keep a custom branch per project... (and it doesn't appear in the API list because this is built separately)

I also relied in third party C++ nodes to create complex graphic paths, that are then passed to the script via data cable, just to get rid of the computational load off the script.

So this dumb idea popped out of my head (but seeing the cold weather it might just be some jammed neurones in my brain being the cause of this...)

Is having a way to create custom third party C++ methods be something that worth a discussion around a pint or is it just a dead-born idea?

[Orvillain]

Can't you just use the cable system to pass data to and from the C++ layer and HISE JS layer?

[griffinboy]

@Orvillain

It sounds like OP has already tried that. And that method does work, sending json packets to a c++ node and back again via global cable works fine. I doubt that Christoph will add anything bespoke for this since it's a method that technically works fine.

I do agree that it feels a little bit hacky to use, but in practice it works and I've not hit any project killing limitations with it yet. You can organise all the offline c++ logic neatly if you create a single node to interface with hisescript, and design a data packet key so that you can call your c++ functions using keyed data packets down global cables and it will know what c++ functions to call based on that.

Possibly a thing that would make a bigger difference is improving the c++ node template with more features and callbacks. I find it quite fiddly to implement proper offline processing in c++ nodes, you have to do all the threading yourself. The nodes feel like they are designed for straightforward sample in sample out processing and the optimizations sometimes step on your feet.

[ustk]

@griffinboy said in Custom third party C++ methods...:

The nodes feel like they are designed for straightforward sample in sample out processing and the optimizations sometimes step on your feet.

That’s precisely it. The node feel and will always feel signal oriented, hence the need for script oriented methods.
Making a node in a network to implement a function on the script side makes me uncomfortable. The threading too, because in the end a script method doesn't have to move out the message thread...

And since a node should still be compiled, I’d rather prefer to implement it as a script method (even if recompiling hise is longer)

That being said it would be interesting to see your implementation process for multiple functions, should you wish to share it of course

[David Healey]

@ustk said in Custom third party C++ methods...:

a custom branch per project.

Why per project? I have one fork + branch where all my customisations go for all project, and if I add something useful to others I push it upstream too.

[ustk]

@David-Healey Yeah very true, that came from a mod I've made for audio inputs that couldn't be shared with other projects, but that's a different matter...