Global Cables Don't Work when compiled

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.

https://github.com/kunitoki/yup

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

ustk

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

you are correct Global Cables DONT work in compiled scriptnode

...

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 don't understand why it would be "exotic edge case" here, and how you can work around this... Seems rather a normal workflow to me...

I have a compiled node in a network, that is (I think) busy enough to justify a compilation too...
And then my global cables won't work...

What can I do?

ustk

@Christoph-Hart And aside of this we still have some nodes like cable_expr that are requiring the network to be compiled for the plugin to export.

I could transform it into a C++ node with another global_cable, but since it prevents the network to be compilable...

This causes quite annoying frictions

Christoph Hart

@ustk can you rearrange your setup so that the global cables are in the outermost network that you compile?

I haven‘t checked / tested the global cable initialisation in C++ nodes to be recursive so it might fail if you try to wrap another node that uses a global cable. Can you check with a simple two level nest test if that‘s the case?

ustk

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

in the outermost network that you compile?

Sorry but I don't understand. My C++ nodes are in the middle of the graph.
Do you mean in the root container?
I tested anyway and same thing, the hardcoded FX rejects it.

Screenshot 2026-08-04 at 18.57.26.png

Screenshot 2026-08-04 at 18.56.47.png

Christoph Hart

@ustk I need a dumbed down representation of the issue so I can reproduce it. My theory is that if you use a C++ node that connects to a global cable internally then this will not survive being wrapped into a network and then recompiled and loaded into a hardcoded FX?

ustk

@Christoph-Hart Yes exactly this, it doesn't survive. i tested with an empty network too (just my C++ node)

Christoph Hart

@ustk ah OK I could reproduce that. The fix is actually not in the HISE code (yet), but the codegen is missing a property of the C++ node so that it knows to add the glue code to connect the internal cables. The solution requires two steps from you:

If you want to use a global cable inside a nested C++ node (a C++ node that is compiled and then loaded into a DSP network that is then again compiled, you will need to add the IsFixRuntimeTarget property to the node_properties.json file. This tells the code generator that the node wants to be notified of global cable assignments (this information is otherwise lost on the layer of the C++ node).

{
  "internal_cpp_node": [
    "IsPolyphonic",
    "IsFixRuntimeTarget",
    "AllowPolyphonic"
  ]
}

However this is only part one of the solution as the code generator will then assume that the C++ node has a second template argument (like any other native HISE node that requires a runtime connection). So in order to compile the generated C++ code of the DSP network you will have to add a second dummy template argument to your external node:

// Use this enum to refer to the cables, eg. this->setGlobalCableValue<GlobalCables::internal_cable>(0.4)
enum class GlobalCables
{
	internal_cable = 0
};
// Subclass your node from this
using cable_manager_t = routing::global_cable_cpp_manager<SN_GLOBAL_CABLE(776606779)>;

// ==========================| The node class with all required callbacks |==========================

// instead of just this:
//template <int NV> struct internal_cpp_node: public data_base

// add this template argument
template <int NV, typename UnusedHash=runtime_target::indexers::none>
 struct internal_cpp_node: public data::base,
                           public cable_manager_t

With these two steps, the global cable connections survives the nested C++ / DSP network structure, so please try if that also solves your actual project. If that's the case, I'll update the documentation accordingly.

ustk

@Christoph-Hart Nice one! It seems to work but I can't fully confirm at the moment because something in my network makes a hard crash as soon it loads in a HCFX...
But it is definitely not the C++ node and compiling it with a fresh network removes the global cable not found warning

Global Cables Don't Work when compiled

8

2.5k

13.9k

121.3k