vMix Forums
»
General
»
General Discussion
»
Why o why are sometimes only Input numbers allowed?
Rank: Advanced Member
Groups: Registered
Joined: 2/18/2014(UTC) Posts: 1,837 Location: Stockholm
Thanks: 144 times Was thanked: 297 time(s) in 250 post(s)
|
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.
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/19/2020(UTC) Posts: 55 Location: London Thanks: 2 times Was thanked: 4 time(s) in 4 post(s)
|
This isn't a problem to anyone else using API calls because that same API also gives you the unique key of the input, which you can see at: http://127.0.0.1:8088/api/? You literally just tell it to reference the key rather than the input number or name. You can even make an incredibly basic (15 lines) script that allows you to have it on a streamdeck key (using companion) and it puts the key on your clipboard for you. If that's not achievable, you really should just have a 'base' project where stuff *doesn't* get moved. Like, we have one where vmix calls are always 1-8, then followed by any output mixes, config inputs etc. This one is seriously what you should be doing, because that's just 'best practice' more than anything else. If you're making brand new projects for every single job, or just taking the same one but perpetually re-hashing it, that will of course cause you to make mistakes by moving inputs around. The addressing an input by a name thing quickly falls over. How does it tell the difference between you asking for "CAM3" vs "CAM3+PPT" for example, without you having to write the *exact* input name, which can just as easily make a mistake in if you miss a space. You can also very incredibly easily have two inputs of exactly the same name - how does it address the difference between "CAM3" and "Virtual - CAM3"? What you're asking for basically already exists in a different form - if you're using API, you should be using the input key.
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 2/18/2014(UTC) Posts: 1,837 Location: Stockholm
Thanks: 144 times Was thanked: 297 time(s) in 250 post(s)
|
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.
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/24/2021(UTC) Posts: 474 Location: athens Thanks: 118 times Was thanked: 68 time(s) in 64 post(s)
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 1/23/2022(UTC) Posts: 91 Location: Milton Keynes Thanks: 13 times Was thanked: 4 time(s) in 4 post(s)
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 11/28/2015(UTC) Posts: 183
Thanks: 10 times Was thanked: 32 time(s) in 27 post(s)
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/24/2021(UTC) Posts: 474 Location: athens Thanks: 118 times Was thanked: 68 time(s) in 64 post(s)
|
Originally Posted by: richardgatarski 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. 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 Code:
API.Function("PreviewInput", Input:="6b5b87ee-2f68-471b-8ccf-d8d764c3b282") 'send the mix input to preview so we can take the correct guid
sleep (50)
API.Function("SetDynamicValue1", Value:="mix2") ' value that will say the companion trigger for which mix input guid we combine it
sleep (1500)
API.Function("SetDynamicValue1", Value:="mix2-done") 'i change this in order to avoid unwanted repeat of the action
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
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 2/18/2014(UTC) Posts: 1,837 Location: Stockholm
Thanks: 144 times Was thanked: 297 time(s) in 250 post(s)
|
I understand that complex vMix scripting might be difficult to grasp in the beginning. But, to repeat my point, for Mix Inputs you can ONLY specify which Mix to switch using its number (1-15). N.b. not the Input number, not the GUID, not the name - only the Mix number. From https://www.vmix.com/help26/Mix.htmlQuote:The following shortcuts can be used with an optional Mix parameter, where 1 is equal to the main mix in vMix and 2 is equal to the first Mix input. PreviewInput ActiveInput Fade, Zoom, Wipe etc
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/8/2022(UTC) Posts: 82 Thanks: 19 times Was thanked: 1 time(s) in 1 post(s)
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/24/2021(UTC) Posts: 474 Location: athens Thanks: 118 times Was thanked: 68 time(s) in 64 post(s)
|
Originally Posted by: richardgatarski I understand that complex vMix scripting might be difficult to grasp in the beginning. But, to repeat my point, for Mix Inputs you can ONLY specify which Mix to switch using its number (1-15). N.b. not the Input number, not the GUID, not the name - only the Mix number. From https://www.vmix.com/help26/Mix.htmlQuote:The following shortcuts can be used with an optional Mix parameter, where 1 is equal to the main mix in vMix and 2 is equal to the first Mix input. PreviewInput ActiveInput Fade, Zoom, Wipe etc I agree with you. But because i know that any company that do any product,have their priorities to do things,im trying everytime to work with the things i have. Thank you for your answer. The thing im searching for now is how to do in companion a trigger that store the dynamic value and then use this trigger inside other triggers Or another way to do things but too far away from my script (zero) knowledge is something like this Make a script that will read mix input guid from a txt file,change-combine the dynamic value and somehow press a button to do the need action or have multiple script that run per need instead of running too namy companion triggers.
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 11/15/2021(UTC) Posts: 72 Thanks: 8 times Was thanked: 9 time(s) in 7 post(s)
|
Originally Posted by: richardgatarski 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. 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.
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/24/2021(UTC) Posts: 474 Location: athens Thanks: 118 times Was thanked: 68 time(s) in 64 post(s)
|
Originally Posted by: Salvatore 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.
Hello. What am i not understand in your message? Something is not clear to me mix 2 mix.png (16kb) downloaded 1 time(s).Except the annoying change of mix input number if the order change, i can select inside Mix2 the Mix4 input.
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 2/18/2014(UTC) Posts: 1,837 Location: Stockholm
Thanks: 144 times Was thanked: 297 time(s) in 250 post(s)
|
Please keep the discussion here to the current topic (problems related to only being able to target shortcut Inputs with its number). Thanks.
|
|
|
|
vMix Forums
»
General
»
General Discussion
»
Why o why are sometimes only Input numbers allowed?
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Important Information:
The vMix Forums uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close