logo

Live Production Software Forums


Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
spinfold  
#1 Posted : Wednesday, January 17, 2024 6:59:00 AM(UTC)
spinfold

Rank: Advanced Member

Groups: Registered
Joined: 1/23/2022(UTC)
Posts: 63
United Kingdom
Location: Milton Keynes

Thanks: 8 times
Was thanked: 1 time(s) in 1 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.
Hypohamish  
#2 Posted : Wednesday, January 17, 2024 8:39:26 AM(UTC)
Hypohamish

Rank: Advanced Member

Groups: Registered
Joined: 12/19/2020(UTC)
Posts: 54
United Kingdom
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.
spinfold  
#3 Posted : Wednesday, January 17, 2024 9:15:24 AM(UTC)
spinfold

Rank: Advanced Member

Groups: Registered
Joined: 1/23/2022(UTC)
Posts: 63
United Kingdom
Location: Milton Keynes

Thanks: 8 times
Was thanked: 1 time(s) in 1 post(s)
Originally Posted by: Hypohamish Go to Quoted Post
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.
nikosman88  
#4 Posted : Wednesday, January 17, 2024 10:47:02 AM(UTC)
nikosman88

Rank: Advanced Member

Groups: Registered
Joined: 12/24/2021(UTC)
Posts: 342
Greece
Location: athens

Thanks: 113 times
Was thanked: 52 time(s) in 49 post(s)
Originally Posted by: spinfold Go to Quoted Post
Originally Posted by: Hypohamish Go to Quoted Post
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
richardgatarski  
#5 Posted : Thursday, January 18, 2024 1:58:26 AM(UTC)
richardgatarski

Rank: Advanced Member

Groups: Registered
Joined: 2/18/2014(UTC)
Posts: 1,812
Location: Stockholm

Thanks: 137 times
Was thanked: 292 time(s) in 246 post(s)
Originally Posted by: Hypohamish Go to Quoted Post
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
Turnipisum  
#6 Posted : Monday, January 22, 2024 11:34:30 PM(UTC)
Turnipisum

Rank: Newbie

Groups: Registered
Joined: 1/22/2024(UTC)
Posts: 1
United Kingdom

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
doggy  
#7 Posted : Tuesday, January 23, 2024 12:05:13 AM(UTC)
doggy

Rank: Advanced Member

Groups: Registered
Joined: 12/27/2012(UTC)
Posts: 5,078
Belgium
Location: Belgium

Thanks: 284 times
Was thanked: 920 time(s) in 759 post(s)
Originally Posted by: Turnipisum Go to Quoted Post
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 ;-)
spinfold  
#8 Posted : Tuesday, January 23, 2024 3:38:56 AM(UTC)
spinfold

Rank: Advanced Member

Groups: Registered
Joined: 1/23/2022(UTC)
Posts: 63
United Kingdom
Location: Milton Keynes

Thanks: 8 times
Was thanked: 1 time(s) in 1 post(s)
Originally Posted by: Turnipisum Go to Quoted Post
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.
Roy Sinclair  
#9 Posted : Thursday, January 25, 2024 11:40:57 AM(UTC)
Roy Sinclair

Rank: Advanced Member

Groups: Registered
Joined: 11/23/2020(UTC)
Posts: 148
United States
Location: Wichita

Thanks: 9 times
Was thanked: 21 time(s) in 17 post(s)
Originally Posted by: spinfold Go to Quoted Post

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.
spinfold  
#10 Posted : Thursday, January 25, 2024 8:58:28 PM(UTC)
spinfold

Rank: Advanced Member

Groups: Registered
Joined: 1/23/2022(UTC)
Posts: 63
United Kingdom
Location: Milton Keynes

Thanks: 8 times
Was thanked: 1 time(s) in 1 post(s)
Originally Posted by: Roy Sinclair Go to Quoted Post
Originally Posted by: spinfold Go to Quoted Post

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".
nikosman88  
#11 Posted : Friday, January 26, 2024 12:08:49 AM(UTC)
nikosman88

Rank: Advanced Member

Groups: Registered
Joined: 12/24/2021(UTC)
Posts: 342
Greece
Location: athens

Thanks: 113 times
Was thanked: 52 time(s) in 49 post(s)
Originally Posted by: spinfold Go to Quoted Post


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.
Users browsing this topic
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.