Use Internal Custom Variables?

Variable seem pretty powerful. Have you thought about implementing internal variables in the RCP module eg for mix, channel and level?

Use case - I have buttons that duck multiple channels and mixes a to a specified level. If we could duck those mixers by $(internal:custom_DuckLevel), we could easily change parameters dynamically.

I had considered variables for values coming from the console, but the sheer number of them would make it difficult to implement and also very slow to load as it retrieved all those values. (eg. just mix levels would need 288 (channels) x 72 (mixes) = 20,736 variables. Add mix on/off, channel fader, channel on/off it would be into the 100’s of 1000’s of variables in no time!)
I’m hoping that there will be a way in the future to set parameters for variables, then this would be something that could be implemented.

Now, I think you are speaking of something different, more like the MY_CHANNEL settings that are in the RCP config screen?

Yeah, more like the MY_CHANNEL settings , which are really useful but maybe using companion’s internal custom variables? So potentially more of them and more flexible.

Copy. I’ll have to investigate that. No documentation I can find atm about how they work or how to implement them so I’ll ask around…

Hello !

Would it be possible for your Companion build to “sniff” the data sent from the console to the network (via the editor maybe) ?
That way you would not have to ask for states of parameters and juste “listen” to them.

Does this makes sense ? :sweat_smile:

Thank you for your suggestion.
That’s not really the issue, it’s more of a UI problem.
Currently, the number field (like a parameter value) only allows numbers, has handy up/down arrows for incrementing and decrementing values, the feedback fields match the action fields, etc.
Now, if you want to use a variable in place of that number, it needs to allow typing in a variable name, not a number. (I believe they look like ${myVariable} or something similar), so now the field has to change its function to allow text like that to be written, which makes it lose all its “number” features.
Similar issue with things like channels, which are drop-downs and won’t accept variable names…
My thought was to maybe add a setting in the config page that enables the use of variables, and changes the fields accordingly. Kinda clunky though.

Wow. The incredible Julian Waller took it upon himself to re-write part of companion to make using variables seamless. (Sorry, just blown away by the companion dev team!)

However, it’s just for values so far. (no drop-downs or other field types). Additional support for other types should be coming in the future.
I will put up a new build here with support for the internal variables, but I need to probably do a short video showing how it works, as variables are INCREDIBLY powerful and I think many will be lost on how to work them properly. I’ll also need folks to do some testing to make sure it doesn’t break anything.

1 Like

Good news. I’m happy to test whenever I get the opportunity.

1 Like

Check out the video and try the build, let me know if I broke anything!

Thank you for diving into this ! Appreciate it :slight_smile:

I’m going to download it and test it.

1 Like

Anyone had a chance to try this yet?

Yes, I’ve had a quick go . I didn’t report back because my testing hasn’t been very thorough yet sorry, just changing fader levels by internal variable. It seems to work perfectly though, thank you! :+1:

The only thing I came across, and it’s not related to the latest variable implementation, is error flagging (typed value turns red) on levels greater than 1000 in relative mode. levels higher than 1000 work, it’s just that the text turns red.

I think the next step for me is to implement it in a page I use to create a virtual green room. It has a program feed created from a bunch of mix minus and hopefully I’ll use a variable to fix and vary the green room program level.

1 Like

Yeah, the max value was 1000 because that equates to +10db, the max fader/mix value. With relatives, you’re right, it could need to be a number higher than that to go from say, -32768 to 0, for example. Something to address next build.