Global Cables Don't Work when compiled

[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.

[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:

1. 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"
  ]
}

2. 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