This is not a Feature Request, because I have given up requesting for Input addressing by using names in all contexts. Something that would help me and apparently tons of other users to avoid catastrophic mistakes simply because an Input is moved. Our workarounds are many. But the problems remain and increase.

Hence this topic only as questions.

One of the nice features with vMix is that one can address an Input by its position number (sequentially from left to right), a GUID (unique fixed identifier assigned to an input) or a name (string of characters). Unfortunately the last option is not always available. Most recently problematic when it comes to Mix Inputs (and many many years before that to Fullscreens and Outputs).

One of the advantages with names is that a name provides a method for us humans to remember what the thing behind the name is and/or does. Let us use Mix Inputs as the example.

Before version 26 we had four submixers. In the context of API numbers 0 to 3, in the context of user interface numbered 1-4. A little bit confusing, but that's the way it is and too late to change. I understand, and can live with that.

We use Mix 2 (position 24, named "Mix-powerpoint") to hold the currently active powerpoint source Input. Mix 3 (position 25, "Mix-presenter") holds the current presenter's camera. Then we use these two Inputs as overlays in Input 21 ("combo") to display a presenter together with its slides.

So, if we want to use another camera in this combo we can do it with an API call. For example, "ActiveInput&Input=CAM1&Mix=2". But if Mix 3 is moved to position 20 it becomes Mix 2 and the API call does not work as intended. Bummer!

I'm rather frustrated by the fact that it is sometimes possible to address Mix inputs using names. For example, "SetMultiViewOverlay&Input=combo&Value=2,Mix-presenter". But not possible to use "ActiveInput&Input=CAM1&Mix=Mix-presenter". Why is that so?

Being able to use Input names instead of Input numbers would mean that our programming would work no matter the Input's numbers. Besides the fact that it would be easier for users (programmers, operators, TD's) to keep track of what all, possibly 25, added submixers are used for.

Any feedback appreciated.

Dear Hypohamish,

I do not understand how your reply is an an answer to my question.

Instead you offer workarounds which sometimes work, sometimes not. For example, try using the key in a script or via the Web API, like Function=ActiveInput&Input=PPT-input&Mix=[try a key here]. Or check how you can select a source for Fullscreen in its dropdown menu.

Please note that I wrote "Our workarounds are many. But the problems remain and increase". I can only speak for myself, but see that many other users (who also know about the "key") want a better fix.

Thanks.

+1.

You`re right. I started to use mix inputs in combination with virtualsets in multiview.I would like to suggest something that may help to do a stable workaround but im not a lot familiar with scripting. For now with the data we have in api i see that mix inputs also have the key (GUID) that is not changing like the mix input number. In the vmix companion module i see that we can do something like this and when all conditions for any mix input is meet to do the action inside the companion trigger
Firefox_Screenshot_2024-01-17T23-01-47.232Z.png (47kb) downloaded 0 time(s).
so in theory if we do in vmix a script like follow for any mix and run this we can do the trick

If 2 mix input (2 and 3) then we need another one companion trigger mix3 guid -->same guid if we swap 2 and 3 place and also for mix3 real mix input we need another 2 triggers (for 2 and 3 position) with the other real guid.. Yes this work!! BUT... If we use all the 15 mix inputs we need 225 triggers to cover all the possible positions for all mix inputs and also this all per action..
So.. because im dummy in scripting. Is there any idea to do what we need and reduce to minimum the variables we use?
Thanks for any answer

+1 !

l’m with you
This topic is a major handicap for our productions. We are currently solving it with various workarounds. It would be nice if something could be improved. I'm wondering why mix Inputs are handled in such a complicated way and with the restrictions.

It would be much easier to handle the mix inputs like camera inputs: Add input - mix - and then simply select the mix number you want ( and not the next free mix number) and give them the same API functions as other Inputs.

Maybe with fix mix numbers can be solved the Re-entrancy Problem also: You can use a Mix input as a source of another Mix input as long as they are done in order. For example using Mix 3 in Mix 4 is possible, but Mix 4 in 2 is not.

Please keep the discussion here to the current topic (problems related to only being able to target shortcut Inputs with its number).
Thanks.