Global Cables Don't Work when compiled

griffinboy

C++ node global cables not working in compiled networks.
The cables work fine in the uncompiled network as seen in the video.

Is there an intentional reason behind this?

I've been told that using hardcoded networks is optimal.
But is this true for c++ nodes?
Since they are already compiled is there any performance gain to compiling twice?

Probably a question for @Christoph-Hart ?

griffinboy

@griffinboy
Wimp womp

griffinboy

@griffinboy bump to top : p ; 3

Orvillain

@griffinboy A silly question, but can compiled networks loaded into a hardcoded slot actually print to the console??

griffinboy

@Orvillain

Yeah should do.
I'm on windows and I use the VS DBG console commands. Pretty sure those work compiled, idk if Hise phases those out but it shouldn't do.

Lindon

@griffinboy you are correct Global Cables DONT work in compiled scriptnode....and I cant recall Christophs reason for it..but it seemed reasonable at the time...so I only ever use them "standalone before and after the HCFX

Orvillain

@Lindon Huhh.... so if you use global cables, don't ever compile your script-node networks and just compile the plugin using the uncompiled networks??? Do I have that right???

Lindon

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

@Lindon Huhh.... so if you use global cables, don't ever compile your script-node networks and just compile the plugin using the uncompiled networks??? Do I have that right???

no, - design your instrument structure so that your effects are in your compiled script nodes - but the signal routing(using Global Cables) are separated out...

Orvillain

@Lindon Hmmmm. So a project I am working on is using a custom c++ node to pipe detected transients to the UI via a data cable. I simply cannot risk that functionality not working, and there is no way to design it in the way you suggest, because I'm not writing an effect as such. I'm writing an internal signal analysis tool that generates data and pushes it elsewhere for further decision making.

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

Global Cables Don't Work when compiled

17

1.7k

11.8k

102.6k