custom C++ module
-
@Christoph-Hart awesome!!! In the meanwhile where can I change in the source that refresh rate to see if I can use Hise today without that lag I'm facing?
-
how about: custom C++ module, using HISE for the interface?
-
@Jay I'm totally a newbie on C++. A friend of mine is helping. Anyway is harder than I thought
-
Hey, sorry for the necro bump. Has anyone had any success doing this???
I've gotten as far as adding some functionality to the AudioLoopPlayer class, but I don't know how to expose the data into the HISE scripting interface or UI. So I can't solidly check whether my code is actually doing the right thing.
-
@griffinboy is your dude, other than the boss himself
-
Ah I wouldn't be so sure!
C++ nodes are my specialty: but my efforts to create fully embedded Hise modules haven't been successful in the past, and honestly I haven't made an effort to succeed yet. I wanted to minimise the amount of fiddling I have to do with the source code every time I want to update Hise to a new version.I thought that I'd ask for some extra features in the c++ nodes down the line to resolve a few of the limitations when it comes to interfacing with the rest of Hise (for things such as graphics and communication of long pieces data).
(If you need help creating a c++ script node synth node for additve, that's another story, that's not tricky. The hard part is efficiency using vectorized math etc)
-
I've built a transient detector in two places, I wanted to compare for performance.
The first implementation is directly in Hise, straight into the Interface.js script. Just blagging it really, using:
const var AudioLoopPlayer1 = Synth.getAudioSampleProcessor("Audio Loop Player1"); const var AudioFile = AudioLoopPlayer1.getAudioFile(0); const var AudioChannels = AudioFile.getContent();And then processing the raw sample data right there. But daaaayyyyummmm this is slow. Even if I process in blocks of 32-128, it is slow.
The second place is directly in the AudioLoopPlayer class. But as you rightly point out, building it there will require rebuilding HISE, and re-applying my updates each time I increment my HISE version. The only reason I was looking at this was for performance.
I haven't yet looked into doing a SNEX node for it, and I'm not sure if it is even possible.
-
C++ scriptnode nodes exist. And you don't have to rewrite any hise source code for that (unless you need to use some external libraries that require that).
The performance of c++ nodes isn't too bad. I haven't compared it against doing straight c++, that would be an interesting thing to benchmark.
-
@griffinboy I guess what I don't quite get is how I would get my transient positions out of a SNEX or c++ scriptnode, and back into the scripting interface so I can draw them on the UI, or otherwise use that data for other things.
Which is why I've shied away from doing it that way.
-
Yep that's to me, one of the big current limitations to nodes. There is likely a way to do it though. I'll have to ask @Christoph-Hart for his opinion
Currently you can communicate with Hise from a custom node using methods like global cables, external data.
I wonder whether we could get a slot for custom data, like for arrays, that is shared between hise UI and custom nodes...Then again, there is likely an existing solution that I'm probably ignorant to.
-
@Orvillain either a global cable which will fire a callback in your script/s every time it sends data or you have a continuous stream of data being output from snex/cpp/faust that you then pick up with the peak/peak_unscaled node, set that node's buffer to external, and then either get data from it on a timer or use a tile (which has a much better graphical performance)
-
@aaronventure Interesting. I genuinely don't know anything about global cables and my ScriptNode understanding is also fairly limited. Guess I need to study up!
-
Global cable only allows you to send one value.
Search for my posts on the forum about c++ nodes with global cable to see.I don't think you can send an array via GC, but maybe I'm wrong
