Cable broadcaster and callback not updating above 1.0

[ustk]

Even if the value reaches a value above 1.0, neither the broadcaster nor the callback fires, it just stops updating.
This is very annoying because a meter can't show the level in the red zone

Fo this example the level in the network is going above 15.0 for the sake of the example and the max value of the cable is set to 2.0 too, so it's not a clipping signal thing...

[Dan Korneff]

I haven't messed with the global cable much. It might be capped at a 1?
Are your meters running on a gain factor of 0-1? If so, you'll need to convert Gain to dB. Then, you need to map the dBFS range to the analog VU meter scale, so that -18 dBFS (or -20 dBFS) aligns with 0 VU on your meter.

EDIT: if your meter is actually PPM, 0 would be referenced to -9 dBFS or -12 dBFS.

[Christoph Hart]

Yes the cable is supposed to send normalised signals from 0.0 to 1.0. You need to attenuate the signal before you send it through there.

On the scripting side you can then use setRange() to convert the value back to your original gain value:

const var gm = Engine.getGlobalRoutingManager();
const var gc = gm.getCable("gain");

gc.setRange(0.0, 4.0); // 4.0 = +12dB overhead
gc.registerCallback(v => Console.print(v), AsyncNotification);

[ustk]

@Christoph-Hart Ok so it's definitely intended behaviour. I was exactly thinking about such a temporary workaround, but it appears it won't be temporary

Side question (and very basic question), why writing AsyncNotification in the CB doesn't throw an error since it is just parameter name that isn't "declared"? I am instead directly writing either false or true directly, thinking it would be better... I don't see where AsyncNotification is seen as a bool

@Dan-Korneff The meters are free as for their range, so the issue here is the input value that is indeed capped. The PPM is switchable to VU and has a calibration knob so the user can fit the plugin into whatever gain chain is the best for their use case. In this example, the calibration is set at 0dBFS so the actual needle is really capped at 0. But yes in a general workflow I tend to mix at either -12 or even more around -18 which I like the best, but since that depends on the mid point of the converters...

[Christoph Hart]

@ustk said in Cable broadcaster and callback not updating above 1.0:

Side question (and very basic question), why writing AsyncNotification in the CB doesn't throw an error since it is just parameter name that isn't "declared"? I am instead directly writing either false or true directly, thinking it would be better... I don't see where AsyncNotification is seen as a bool

Console.print(AsyncNotification); // 912

It's a magic number that is hardcoded in the engine and converted to the proper bool value for all functions that expect a parameter that indicates asynchronous execution. The rationale for this is code clarity - what is true in the context of synchronosity? Synchronous or asynchronous? You would always have to lookup the API call docs but with this it's super clear what is happening).

[ustk]

@Christoph-Hart It's true that you're right! But my brain, him, is async...