Rank: Advanced Member
Groups: Registered
Joined: 1/23/2022(UTC) Posts: 71  Location: Milton Keynes Thanks: 9 times
Was thanked: 2 time(s) in 2 post(s)
|
Just noticed this in the beta but I assume it's also present in the current v26 release as well.
With mix inputs, if you change the position of the input within the multiview the mix number changes so that the mix numbers always go in sequential order.
For example if I have Mix2 on input #10 and Mix3 on input #15, and I then move Mix3 to input #5, then what was Mix3 becomes Mix2 and what was Mix2 becomes Mix3.
This obviously screws up all my button and trigger programming, where I have a button which cuts Mix3 I then need to change it to be Mix2 instead.
I know the same thing happens with any input when its order changes, but Mix inputs are a bit different because you are forced to choose a number rather than having the ability to choose the name of the input.
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/19/2020(UTC) Posts: 54 Location: London Thanks: 2 times
Was thanked: 3 time(s) in 3 post(s)
|
This is expected behaviour to me - I would dislike it to be any other way, because as you said, *all* inputs act that way, and there are no inputs that defy the rule. If you move it to before another mix, it changes it. Otherwise how could you ever move Mix3 to be Mix2 instead, without adding extra config/settings?
And what would the behaviour be if you closed Mix2? Would you expect Mix3 to be Mix3?
I'll agree that yes, it's annoying if you've programmed buttons to a mix, but then just ensure you keep your mixes in the order they were when you made the buttons for them.
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 1/23/2022(UTC) Posts: 71 Location: Milton Keynes Thanks: 9 times
Was thanked: 2 time(s) in 2 post(s)
|
Originally Posted by: Hypohamish  This is expected behaviour to me - I would dislike it to be any other way, because as you said, *all* inputs act that way, and there are no inputs that defy the rule. If you move it to before another mix, it changes it. Otherwise how could you ever move Mix3 to be Mix2 instead, without adding extra config/settings?
And what would the behaviour be if you closed Mix2? Would you expect Mix3 to be Mix3?
I'll agree that yes, it's annoying if you've programmed buttons to a mix, but then just ensure you keep your mixes in the order they were when you made the buttons for them. Hmm, I hadn't considered that. One solution would be to allow you to choose the mix number when adding an input - ie you could choose to assign your only mix input to be Mix14 if you so wished. And then Change the input to assign a different (spare) number. However the more flexible and logical solution would be to allow referencing the mix input by name/GUID as you can with every other type of input.
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/24/2021(UTC) Posts: 350  Location: athens Thanks: 113 times
Was thanked: 53 time(s) in 50 post(s)
|
Originally Posted by: spinfold Originally Posted by: Hypohamish This is expected behaviour to me - I would dislike it to be any other way, because as you said, *all* inputs act that way, and there are no inputs that defy the rule. If you move it to before another mix, it changes it. Otherwise how could you ever move Mix3 to be Mix2 instead, without adding extra config/settings?
And what would the behaviour be if you closed Mix2? Would you expect Mix3 to be Mix3?
I'll agree that yes, it's annoying if you've programmed buttons to a mix, but then just ensure you keep your mixes in the order they were when you made the buttons for them. Hmm, I hadn't considered that. One solution would be to allow you to choose the mix number when adding an input - ie you could choose to assign your only mix input to be Mix14 if you so wished. And then Change the input to assign a different (spare) number. However the more flexible and logical solution would be to allow referencing the mix input by name/GUID as you can with every other type of input. Hello for features we must write in the specific area in the forum. I also agree with you. For now something that may work is to make a script that will store as dynamic value the guid from any mix that remains same and then compare this and decide where to send the command I found a somehow way to do it in my last days favorite program (bitfocus companion) but i think a clean way script will be much better
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 2/18/2014(UTC)
Posts: 1,819
Location: Stockholm
Thanks: 138 times
Was thanked: 292 time(s) in 246 post(s)
|
Originally Posted by: Hypohamish And what would the behaviour be if you closed Mix2? Would you expect Mix3 to be Mix3? We all use vMix in many different ways. Personally I had once created a Preset with many Inputs, including Mix 1, Mix 2, and Mix 3. Later on I decided I did not need Mix2, deleted it - and many of my shortcuts, scripts and Companion Actions referring to Mix 3 did not work (since it became Mix 2). I know that many more vMix users besides me use the name/GUID of Inputs to overcome the problems of deleted Inputs and moving Inputs around. Unfortunately, the Mix Inputs can ONLY be referred to by using its Mix number (i.e. 1-15). I have brought that up earlier in Why o why are sometimes only Input numbers allowed?Cheers, /richard
|
|
|
|
|
|
Rank: Newbie
Groups: Registered
Joined: 1/22/2024(UTC) Posts: 1
|
I would like to see static id's related to inputs. It is a nightmare when you move or delete one of them when you can have some much linked to that input.
With static id's you can reorder and delete inputs without adverse affect on other functions in your vmix show.
Cheers
Dean
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/27/2012(UTC) Posts: 5,088  Location: Belgium Thanks: 284 times
Was thanked: 920 time(s) in 759 post(s)
|
Originally Posted by: Turnipisum I would like to see static id's related to inputs. It is a nightmare when you move or delete one of them when you can have some much linked to that input.
With static id's you can reorder and delete inputs without adverse affect on other functions in your vmix show.
Cheers
Dean They are called "key" and can be found in the API XML Using heir names also works Except for Mix inputs what this discussion is about ;-)
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 1/23/2022(UTC) Posts: 71 Location: Milton Keynes Thanks: 9 times
Was thanked: 2 time(s) in 2 post(s)
|
Originally Posted by: Turnipisum I would like to see static id's related to inputs. It is a nightmare when you move or delete one of them when you can have some much linked to that input.
With static id's you can reorder and delete inputs without adverse affect on other functions in your vmix show.
Cheers
Dean For most inputs you can use the input name, which you are in control of. If you move the order of the inputs, the name won't change. If you want even finer control you can use the GUID. This doesn't change if you reorder or rename, so is the most "solid and stable", but it's a pain to find for each input, and means nothing to you at a glance. I prefer the name method, and have a system of naming inputs to ensure no duplicates, mixed case, etc. However this topic is referring to mix inputs, which - while they can be named, and have a GUID, and indeed an input number - cannot be referenced in any way other than its sequential mix number, which is a pain for referencing because as soon as it moves around, all the programming stop working.
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 11/23/2020(UTC) Posts: 154  Location: Wichita Thanks: 9 times
Was thanked: 22 time(s) in 18 post(s)
|
Originally Posted by: spinfold
For most inputs you can use the input name, which you are in control of. If you move the order of the inputs, the name won't change.
If you want even finer control you can use the GUID. This doesn't change if you reorder or rename, so is the most "solid and stable", but it's a pain to find for each input, and means nothing to you at a glance.
I prefer the name method, and have a system of naming inputs to ensure no duplicates, mixed case, etc.
However this topic is referring to mix inputs, which - while they can be named, and have a GUID, and indeed an input number - cannot be referenced in any way other than its sequential mix number, which is a pain for referencing because as soon as it moves around, all the programming stop working.
Finding the GUID is easy, start vMix and enter "http://localhost:8088/api" as the URL and vMix will give you the API.XML response that will show you a list of the inputs and pertinent information about each input. Example Input information from API.XML Code:
<input key="f1058c48-afee-41c3-80e2-e571e9f43a30" number="3" type="Stream" title="Right (West) Camera" shortTitle="Right (West) Camera" state="Running" position="0" duration="0" loop="False" muted="True" volume="38.95009" balance="0" solo="False" soloPFL="False" audiobusses="M" meterF1="0" meterF2="0" gainDb="0">
Right (West) Camera
<cc saturation="0.115"/>
</input>
The "key=" field is the GUID, the "Number=" field is the input number and the "title=" field is the name of the input. Nothing difficult about finding the GUID at all and since it's the one item that will NOT change unless you delete the input and add it back again it's the field you should use when scripting UNLESS you are indeed deleting and adding inputs a lot. Then a method like you use to ensure no duplicate names is probably a good idea though any script referencing an input that might be deleted should check and make sure the input is present first thing so it doesn't make changes that will malfunction.
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 1/23/2022(UTC) Posts: 71 Location: Milton Keynes Thanks: 9 times
Was thanked: 2 time(s) in 2 post(s)
|
Originally Posted by: Roy Sinclair Originally Posted by: spinfold
For most inputs you can use the input name, which you are in control of. If you move the order of the inputs, the name won't change.
If you want even finer control you can use the GUID. This doesn't change if you reorder or rename, so is the most "solid and stable", but it's a pain to find for each input, and means nothing to you at a glance.
I prefer the name method, and have a system of naming inputs to ensure no duplicates, mixed case, etc.
However this topic is referring to mix inputs, which - while they can be named, and have a GUID, and indeed an input number - cannot be referenced in any way other than its sequential mix number, which is a pain for referencing because as soon as it moves around, all the programming stop working.
Finding the GUID is easy, start vMix and enter "http://localhost:8088/api" as the URL and vMix will give you the API.XML response that will show you a list of the inputs and pertinent information about each input. Example Input information from API.XML Code:
<input key="f1058c48-afee-41c3-80e2-e571e9f43a30" number="3" type="Stream" title="Right (West) Camera" shortTitle="Right (West) Camera" state="Running" position="0" duration="0" loop="False" muted="True" volume="38.95009" balance="0" solo="False" soloPFL="False" audiobusses="M" meterF1="0" meterF2="0" gainDb="0">
Right (West) Camera
<cc saturation="0.115"/>
</input>
The "key=" field is the GUID, the "Number=" field is the input number and the "title=" field is the name of the input. Nothing difficult about finding the GUID at all and since it's the one item that will NOT change unless you delete the input and add it back again it's the field you should use when scripting UNLESS you are indeed deleting and adding inputs a lot. Then a method like you use to ensure no duplicate names is probably a good idea though any script referencing an input that might be deleted should check and make sure the input is present first thing so it doesn't make changes that will malfunction. It's not easy when you have 100+ inputs. Also, as I mentioned, the long string means nothing at a glance. When I'm looking through a stack of 10 Companion commands on one button, I can tell instantly using names whether the input it's affecting is "Right (West) Camera" or "Left (East) Camera".
|
|
|
|
|
|
Rank: Advanced Member
Groups: Registered
Joined: 12/24/2021(UTC) Posts: 350 Location: athens Thanks: 113 times
Was thanked: 53 time(s) in 50 post(s)
|
Originally Posted by: spinfold
It's not easy when you have 100+ inputs.
Also, as I mentioned, the long string means nothing at a glance. When I'm looking through a stack of 10 Companion commands on one button, I can tell instantly using names whether the input it's affecting is "Right (West) Camera" or "Left (East) Camera".
In human eyes/brain means nothing but in vmix machine language is the most reliable. Also i see that this thread has been moved to general discussion from beta thread and not in features, so i assume that it is not a thing that will be implemented soon. And we need to continue by using workaround.
|
|
|
|
|
|
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
