vMix provides through its API an XML tree with state information about the current preset. Unfortunately, this state tree lacks many useful information and hence provides only an insufficient/partial state information. This limits the possibilities of extension scripts dramatically! Just a few examples of the missing information:
a VirtualSet has overlays which can be found under the XPath /vmix/inputs/input[…]/overlay but this has just an index and key attributes and especially does not tell you the key of the currently ASSIGNED input
inputs can have 10 layers and when you assign an input to it, you cannot see information about them under /vmix/inputs/input[…]/
Audio inputs have a /vmix/inputs/input[…]/@solo attribute but Audio busses do not have such an attribute to reflect their “Solo” button
For the API calls PreviewInput/ActiveInput one needs the Mix argument in order to configure one of the custom mixes 1-3. Unfortunately, there is no way to find out which input name corresponds to the mixes 1-3 programatically, as the /vmix/inputs/input[…]/ have no attribute showing the Mix-number (just the input number, which is different).
Workaround: none
Recommendation: expose really all information and state of all inputs, so scripts can react upon those states and information.
vMix provides through its API an XML tree with state information about the current preset. Unfortunately, this state tree lacks many useful information and hence provides only an insufficient/partial state information. This limits the possibilities of extension scripts dramatically! Just a few examples of the missing information:
/vmix/inputs/input[…]/overlaybut this has just an index and key attributes and especially does not tell you the key of the currently ASSIGNED input/vmix/inputs/input[…]//vmix/inputs/input[…]/@soloattribute but Audio busses do not have such an attribute to reflect their “Solo” buttonPreviewInput/ActiveInputone needs theMixargument in order to configure one of the custom mixes 1-3. Unfortunately, there is no way to find out which input name corresponds to the mixes 1-3 programatically, as the/vmix/inputs/input[…]/have no attribute showing the Mix-number (just the input number, which is different).Workaround: none
Recommendation: expose really all information and state of all inputs, so scripts can react upon those states and information.