Global cable in Hardcoded FX working, then not, then yes, then...

[ustk]

!!! THE ISSUE WAS NOT ABOUT THE CABLES !!! answer below, post #10

Alright so I have global cables just to read values on the UI

They ARE working great in the ScriptFX network
They WERE working great in the compiled DLL (HardcodedFX)
I did modified the networks many many times and still the global cables were working in the exported DLL and HardcodedFX.

Then suddenly, one modification later (not even related to global cables), they refuse to work in the exported DLL, despite they still do in the ScriptFX networks...

I tried to remove the DLL, re-export, unload/reload/save/close/open a bunch of times... No, they don't want to reconnect to the Hardcoded modules...

Any clue on this?
Is there a "force to find what you need to connect to" hidden menu?

[ustk]

Oh, and I should mention that its not all the cables.
For instance I have two in a network where the first is working and not the second... So it's definitely a "lost connection" thing... I'll try to investigate the .h exported network but I doubt being able to find anything...

[ustk]

Alright this just getting crazier each time...

I deleted the binary folder and re-exported the DLLs, some cables came back but not all.

I did not touch the ones that were working and just unloaded the DLL of the ones that weren't working.
Restarted the project, load the DLL, no cables are working anymore even the ones that were in the DLL I haven't touched!

[ustk]

@Christoph-Hart Ok so there still seem to be a connection issue somewhere that I am not able to track down in the generated header file for the DLLs, or the XMLs (everything seems to be fine when compared to a simple test project that is working once compiled)

I have found several posts about that, and you apparently fixed something (commit 8a0d61f, oct. 5th), but the issue is still there, be it related or not.

The cables are defined in the script:

const var GRM = Engine.getGlobalRoutingManager();

const var GC_BassLevelCable 	= GRM.getCable("GC_BassLevel");
const var GC_BassCompLevelCable = GRM.getCable("GC_BassCompLevel");
const var GC_ExciterLevelCable 	= GRM.getCable("GC_ExciterLevel");
GC_BassLevelCable.setRange(0.0, 1.0);
GC_BassCompLevelCable.setRange(0.0, 1.0);
GC_ExciterLevelCable.setRange(0.0, 1.0);

GC_BassLevelCable.registerCallback(function(value)
{
    // do something
}, false);

GC_BassCompLevelCable.registerCallback(function(value)
{
    // do something
}, false);

GC_ExciterLevelCable.registerCallback(function(value)
{
    // do something
}, false);

And showing properly:

Some related posts:
https://forum.hise.audio/topic/10633/global-cable-not-working-in-compiled-vst/17
https://forum.hise.audio/topic/10724/global-cable-bug/2

Quick recap:

• They are always working with ScriptFX
• They may (rarely) connect with HardcodedFX

I can send over to you my project if it can help to track down the issue as I am really stuck with this, and to my knowledge, this is the only way to get a value from a compiled DLL back to the UI.

[HISEnberg]

@griffinboy sounds very familiar.

@ustk I had this happen very recently to me (it's quite stressful). I forget what I did (if I even did anything), but I managed to get them working again. Just wondering if you clear them from the network, compile the network, add them back in (perhaps with new slot names), does that work for you? Still that would only be a temporary solution, it would be nice to get the bug fixed.

[griffinboy]

@ustk

This happened to me on a large project. I haven't recovered it yet. My idea was to start from scratch and slowly recreate everything until I discover the issue.

A massive pain for a huge project. I can't offer any help yet as I haven't done it, but that was the only thing I could think to do next, as we tried everything else.

[ustk]

@HISEnberg @griffinboy Thanks guys

Yeah I tried all of those, and much more. Removed modules, changed node IDs, deleted cables, cleaned binary folders entirely, even moved the code to the beginning of the onInit script to be sure cables are created asap, tried with broadcaster and cable callbacks...
But none of those gave a satisfying result. They can rarely connect, most of the time they cannot, with no clue on the differences that brings these different results...

[griffinboy]

@ustk

Oh dear xD
That doesn't bode well for the work I was planning to do in the future to mix my project.

Global cables have been a bit broken-ish for a long while.

[ustk]

@griffinboy @HISEnberg @Christoph-Hart Alright guys, so I've been TOTALLY FOOLED by this sunny Sunday! It appears the issue DOES NOT come from Global Cables.
They are triggering the callbacks but the value is so tiny (e-17 exponent value at most...) that I couldn't see anything. Yeah in fact I could if I would have printed the value at the right moment but I was so blind trying different things... Arffff...

For some reasons, it's the Enveloppe Follower that does not modulate the Global Cable once compiled!
Everything is up and running when using the network, but the DLL makes the Enveloppe Follower silent...

Here are screenshots in order of appearance (, and UI with HardcodedFX)

Script FX Network

ScriptUI with ScriptFX

ScriptHardcodedFX Module

ScriptUI with HardcodedFX

[ustk]

Alright so I finally have good news! I can confirm the Global Cables are indeed working, so I solved my problem by removing the modulation connection from the Attack of the Enveloppe Follower.
As soon as it is connected to a modulator, it refuses to work in a DLL

But connected straight to a Parameter it does work:

@Christoph-Hart Any idea about what could cause this issue?

[griffinboy]

@ustk

Ah great that it's starting to work!. In my project, it actually works when freshly compiled, but if you save and reload the project its broken! I haven't checked on the project in a few months, so perhaps its time for me to reconfirm... It possible my issue has been resolved.

[ustk]

@griffinboy It's stable here, finger crossed it'll work on your side!

[orange]

@ustk I wonder, what is the reason for modulating the envelope follower's attack?

[ustk]

@orange Well it’s not modulation per say as a matter of time modification but it was just connected to a control so I could chose between two constant values. But this two states switch is still seen as "modulation" by Hise

I've just encountered the problem again in another network so I opened an issue on GitHub