Global Cables Don't Work when compiled

[Christoph Hart]

you are correct Global Cables DONT work in compiled scriptnode

Wrong. This was the case, but now they work and you can even send arbitrary data through it (which will get copied though so it might not be the fastest option).

I think the issue that @griffinboy is having is if you load these networks into another scriptnode network (instead of loading the compiled effect into a hardcoded effect), but that's another problem and (potentially exotic edge case which you can easily work around).

I'm writing an internal signal analysis tool that generates data and pushes it elsewhere for further decision making.

That's precisely what the global cables are made for. The only thing you have to watch out for is that you "create" them in your script before using them in the compiled effect.

[Lindon]

@Christoph-Hart said in Global Cables Don't Work when compiled:

you are correct Global Cables DONT work in compiled scriptnode

Wrong. This was the case, but now they work and you can even send arbitrary data through it (which will get copied though so it might not be the fastest option).

well that's good news.

[Orvillain]

@Christoph-Hart said in Global Cables Don't Work when compiled:

That's precisely what the global cables are made for. The only thing you have to watch out for is that you "create" them in your script before using them in the compiled effect.

Lovely stuff. Yeah, it did baffle me a bit the idea they wouldn't work, because I've been using them in a compiled plugin. But I haven't been compiling my networks when doing so.

Which brings up possibly a n00b question - when I compile a plugin, does that automatically compile networks, or only if the network has the allowCompilation flag enabled?

[Christoph Hart]

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

when I compile a plugin, does that automatically compile networks, or only if the network has the allowCompilation flag enabled?

It does not compile any networks automatically - we've been over this a few times and there is literally no solution that won't mess up any workflow.

If you're writing C++ nodes, you shouldn't touch any scriptnode network at all but directly add it into the hardcoded FX modules, this way you have no overhead & the best development experience.

[griffinboy]

@Christoph-Hart

Thanks for clearing that up.
The reason I had to have my node inside another network was that I am feeding it event data.

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

[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