Add internal variables with knowledge of actions

[richardwilliamson]

Hello

For us it would be really useful to be able to pull variables from a button's actions - for example, I work with Ash on zoomOSC and we have an undefined number of users in a call. We will define a button to act on a user in a call (such as pin them) via various routes - such as by gallery position

Currently to have a title which reflects the username of the user which the button controls we have to set the action to gallery positon x, y and then provide a variable of zoomosc:galleryPosition_x_y_username - which makes for a lot of variables and there is a lot of duplication required by a user when setting up an action.

What I would propose is that a button is able to pull variables from its actions - in the form of:
$(internal:action_0_username) - which would query the action at index 0 for the variable username. If the action doesn't provide this variable $NA or similar would be displayed as is currently the case for missing variables.

I am happy to have a look at implementing this in core - but wanted to see if anyone has any moral objections before I spend much time on it.

Thanks!

[dnmeid]

I'm afraid I'm a little confused by the terminology you are using. If I get you right you want to use parameters of actions to be usable on bank text.
In you example there would be an action which has a parameter called username and whatever the value of this parameter is, should replace the $(internal:action_0_username) placeholder.

If this is correct, I'd say go for it. But I'd suggest to use a little different syntax. Instead of action_0_username, I'd prefer a numerical index for action and parameter. The reason is that the users don't know the internal parameter id, they just see the descriptive parameter name. The name can contain spaces and generally may not be suited for forming a placeholder. Even better would be to make the whole config available automatically in a tree format like bank.1.2.down.0.1.value to get the value of the second parameter of the first down action of bank 2 on page 1. Or bank.1.2.up.1.name to get the name of the second up action of bank 2 on page 1. bank.0.0 could serve as this bank and bank.0.4 as bank 4 on this page and bank.3.0 as this bank number on page 3.

In the long term I would prefer to go the other way round. That means a way to use variables as parameters, which has been requested before. That way you could define a variable "username1" and set it "John Doe". Now you could use the variable in the text of the bank and in the parameter of an action.

[richardwilliamson]

Thanks @dnmeid and apoligies that my description was not clear. I think what you are suggesting is similar to what I'm thinking (and you are correct to point out the need to specify whether the action is on the down or up), I'm not clear of the need to specify the parameter by ID rather than name though - since my use case would involve the instance being adapted to offer these variables (and so the names would not have spaces etc).

I will have a ponder on it and see if I can get a proof of concept working

[Julusian]

Couldnt the setup of these buttons be automated with presets? It isnt as elegant as what you are proposing, but might negate the need for it.

I'm not keen on making the whole config available. For one this it will make moving these buttons a nightmare, and it will add a lot of variables and corresponding data updates. Referencing the local value will be a little panful to get the data flow correct though.

There is some risk with using indexes like @dnmeid proposes, in that changes to the actions could cause the data found to not be what is expected, but I agree with the points about the names, but that could instead be solved by doing some basic fixup of the names in this variables system (replace anything not a-z, 0-9 or _ with _).
A good example of where index behaviour could play up is the bmd-atem module. For some actions it skips some dropdowns when connected to a model which can only offer one option.

[Julusian]

I agree that this isn't the right approach. Instead we should do #1909 so that a variable can be defined on the button, which can then be referenced by the actions/feedbacks/text