I was similarly looking for a way to automate loading the next sequential input into preview after an input goes to output. In my case it is not that the order of input playback will necessarily change, but we are doing a live remote theatre performance where we want the operator not to have to worry about loading inputs into preview... only pushing the "GO" button. This is especially critical because the software operation is being done through Zoom screen control so we want to streamline the actions required by the operator as much as possible.
This thread was the most helpful thing I could find for this but the solution above involves assigning two triggers with delay times to every single input. This is not ideal because of the extra effort to assign TWO triggers to every input and the unreferenced delay times that will be built into those triggers. If you want the load-into-preview to happen as quickly as possible after a transition ends, and you might change your default transition time during rehearsal, it is perhaps not wise to manually assign the delays in the triggers of each input. It may be better to trigger a script which begins with a delay and then executes the previewing of the next input. This allows immediate tweaking of the default delay time for all inputs. If you have an input that will need to transition at a time longer than the delay built into the script, additional delay can be added to the trigger execution of the input.
This is the "Preview Next Input" script:
sleep(2000)
API.Function("PreviewInput",Input:=-1)
sleep(10)
API.Function("PreviewInputNext")
With comments added:
sleep(2000)
'This first delay is critical to make sure the transition into the input has ended; do not make this much longer than your most commonly used transition time or the programming/testing process becomes quite annoying waiting for inputs to preview -and- operators may get into trouble if they activate a cue late during a fast sequence of cues.
API.Function("PreviewInput",Input:=-1)
'We must momentarily put the active input also into preview so we can use the PreviewNextInput command; -1 is the number of the active (currently going to output) input.
sleep(10) 'Momentary delay to ensure active input is loaded into preview
API.Function("PreviewInputNext")
'Load the next sequential input number into preview. Especially if organizing inputs into tabs; be sure your input tiles are actually ordered sequentially.
About transition timing:
For our show we are most commonly using Merge (set to transition button 1), and occasionally Cut. Our default Merge time is 1500ms and when we want to deviate from that I am attaching a trigger to the preceding input to set the time of transition button 1. If the transition time is longer than the delay time in the above "Preview Next Input" script, I further delay the triggering of the script. I then attach a trigger to the next sequential input to restore the default transition time. The restoration to the default transition time is also being accomplished with a script so that the default time can be easily changed for all inputs. The default time script is also attached to the first input in the show sequence to ensure the correct default time is used from the very beginning.
The script "Set Default Time" is one line: API.Function("SetTransitionDuration1",Value:=1500)
Software feature comments/questions:
-It seems bizarre to me that there is not a mechanism within vMix to trigger actions relative to when a transition ENDS. Why must we institute trigger delay times relative to when a transition (in or out) BEGINS? This requires a completely unnecessary anticipation of the transition time. See feature request here:
https://forums.vmix.com/...sitionOut-Trigger-Option-Also, why must we type or paste the name of the script we want to call into the trigger field? Why is there not a drop-down box to select the script you want to attach to a trigger?
-The convention to push the "Edit" button to save changes to a trigger is extremely counterintuitive and results in accidentally not saving changes to triggers. It is common GUI practice for an "Edit" button to open options to edit something and a "Save" button to confirm the changes. Why is "Edit" being used in place of "Save" or "Save Changes"?
