Global Cables Don't Work when compiled

[griffinboy]

@Orvillain

My workaround was to create a communication node. This node was left uncompiled.

Because the c++ nodes all exist in the same namespace you can communicate between them. So I created an interface where I can send data from my compiled node over to the communication node, which would then send it down a global cable.
Since global cables are 'slow' from my understanding, the extra step probably doesn't hurt. I'm throttling the update speed of the cables anyway because GCs copy all the data so if your data is big it'll be doing lots of work.

But from what christoph has shared, it seems that you can get GCs working in a compiled node, by loading your c++ node by itself into a hard coded network.

[Christoph Hart]

Is there a way to pick up event data callbacks (event data reader node) directly inside of a c++ node?

Yes:

// instantiate this as a class member and forward those callbacks to it:
// -prepare()
// -reset()
// -handleHiseEvent()
scriptnode::routing::event_data_reader<NV> obj;

// somewhere where you want to check if there is a new event data value:
double mv;
if(obj.getWrappedObject().handleModulation(mv))
{
	// there's a change in the event data
	// do something here...
}

}

[griffinboy]

@Christoph-Hart

Based.

I've been gradually working my way through the scriptnode / snex source.
And the amount of stuff in there is incredible.
It really makes me think that so much is possible. You've built out so many nice systems indeed

I started my own fork of juce to try and get around graphics limitations in Hise (using visage), but looking at your source, I could never flesh out something so expansive makes me want to just wait for an eventual future update haha

[Christoph Hart]

@griffinboy said in Global Cables Don't Work when compiled:

I started my own fork of juce to try and get around graphics limitations in Hise (using visage)

Have you found a way to embed a Visage component into a JUCE UI? That's the new UI framework from the Vital guy, right? If that's possible then we could talk about a "HighPerformencePanel" component powered by this framework...

[griffinboy]

@Christoph-Hart

oof, yeah that would be really great wouldn't it.
I haven't, but i'll look into it. I may have to pester him about it directly : )
I've been having some silly dependency issues, even getting it work normally. I'm new to cmake and it's not super fun to learn it xD

I'll see if I can get that to happen.

[griffinboy]

@Christoph-Hart

mmm, the people in the Audio Programmer Discord aren't recommending it XD
It does look like a big amount of pain

[HISEnberg]

@griffinboy What about the yup framework as an alternative? I imagine the integration to HISE would be somewhat complicated as well.

GitHub - kunitoki/yup: YUP is an open-source library dedicated to empowering developers with advanced tools for cross-platform application development.

YUP is an open-source library dedicated to empowering developers with advanced tools for cross-platform application development. - kunitoki/yup

GitHub (github.com)

I have been meaning to get my hands dirty with it but I have only scratched the surface so far.

I definitely like the idea of a High-Performance Panel however, it would let us experiment with more advanced graphics without requiring a complete overhaul of HISE's graphic's framework.

[Christoph Hart]

@griffinboy yeah that was also my initial assessment.

[griffinboy]

@Christoph-Hart

They said it would be better to overhaul using bgfx directly xD
Yeah, not a small task probably. Ah well.

[griffinboy]

@Christoph-Hart

well, all hope is not lost lol