Blackmagic Forum

I'm creating a macro to take a keyer off the air as one of a dozen steps. When recording the macro and clicking my way through the sequence of steps, one of the steps is to click the keyer to take it off air. So far so good, and the macro works fine.

But the state of the keyer in our case is unknown when the macro needs to run. Sometimes the keyer is on and other times might already be off. So if the keyer is already off, clicking the keyer button when creating the macro will turn the keyer on when the macro runs. One of the important functions of this macro is to ensure the keyer is always off.

Other than recording a separate macro to use if the keyer is already off, and potty training the operators to know which macros to use (this introduces the strong possibility of human error with volunteer operators), is there a way to code a macro so that it can test the state of the keyer, and only "click" the keyer if it is in the "on" state?

Maybe I missed it, but the macro recording process has no method that I am aware of to "test" the state of a switcher function, and then execute some conditional XML (or not) as appropriate to the ATEM function's state.

I'm OK coding XML if needed although a snippet example would help speed things along - but don't know if BMD has provided a way to test the state of an ATEM function like a keyer (or anything else).

Suggestions?

Quick update - in researching the capabilities of XML - it appears XML does not support conditional expressions. So there's no way to execute an XML code branch that is based on a specific state of the ATEM.

But I also see that others on the forum are looking for conditional control of their macros. So here's a relatively simple product enhancement request for BMD to consider.

The ATEM's XML syntax and semantics don't support a "force" option. The normal macro "record" process would default to the current behavior which toggles a keyer or or off. But it would be quite simple to force a keyer on or off regardless of its current state, if BMD added an additional parameter and argument to the current XML syntax.

For example, the current syntax could be modified to include a mechanism to force a specific state (on or off) with the following sort of modified XML. Apologies to all if I have the XML syntax wrong - I'm not an XML programmer. But this should be close enough to communicate the basic idea:

The current XML syntax that is generated when I record a macro and and click Keyer2 is:

<Op id="TransitionSource" mixEffectBlockIndex="0" source="Background, Key2"/>

This could be modified to:

<Op id="TransitionSource" mixEffectBlockIndex="0" source="Background, Key2", force="argument" />

An argument of "default" above would simply toggle the state of Keyer2 as would be the case via the default macro recording mechanism.

However in my case, I could record the macro, and then edit the XML on a computer to something like the following, and then "restore" the modified XML back into the ATEM to change its macro behavior to what I require.

<Op id="TransitionSource" mixEffectBlockIndex="0" source="Background, Key2", force="on" />
<Op id="TransitionSource" mixEffectBlockIndex="0" source="Background, Key2", force="off" />

Editing the XML to modify the default argument to "on" or "off" would force keyer2 on or off regardless of its current state - which would be a massive help in creating more powerful and useful macros.

Similar enhancements could be applied to almost anything in the ATEM and could open up a wide variety on new application uses of the ATEM product line.

BMD would need to publish a document describing the enhanced XML syntax and semantics for those who want to edit the XML and then restore the edited macros to take advantage of the additional arguments.

Hello Ethan. It's good to see people get into macro details. Your ideas are good for sure. At the moment, the ATEM macro system is only capable of recording actions and no conditionals as you have observed. I would like to point out that all of the keyer On/Off states are absolute in the macro system, so you can specifically program a key on or off directly. This is two separate macros that turn the DSK on or off.

<Macro index="6" name="DSK1 On" description="">
<Op id="DownstreamKeyOnAir" keyIndex="0" onAir="True"/>
</Macro>
<Macro index="7" name="DSK 1 Off" description="">
<Op id="DownstreamKeyOnAir" keyIndex="0" onAir="False"/>
</Macro>

What you and others are probably interested in is the ability to Auto On or Auto Off rather than a hard cut. The Auto button simply initiates the auto transition process without knowledge of the current state. This would be a nice feature as you suggest. I will also say there are 3rd party macro systems that are built from the SDK that do have the capability of decoding the state.

Regards, Gary

XML is really a markup language rather than a programming language, which is why it does not contain any built-in conditional constructs.

The interpretation of XML markup tags is defined by the author of the XML schema (if there is one) that defines what tags and attributes are allowed as part of a particular XML document. In the case of the ATEM macro XML, Blackmagic has defined the <Macro> and <Op> tags and what these tags mean (that particular operations will get executed on the ATEM switcher). There are lots of other XML documents that just include data and have nothing to do with execution at all.

Having said that, there is nothing inherent in XML that prevents the inclusion of some kind of conditional expressions in the macro XML, these could be added as additional attributes or elements to the XML. For example, XSLT is an XML based language that includes conditional expressions in this way (using <if> elements).

But Blackmagic would have to add this support to the macro XML language because the ATEM switcher would need to process these conditional expressions in the XML. And it could make the macro execution engine in the ATEM quite a bit more complicated depending on what kind of conditions are supported. So I guess I'm not too surprised that this hasn't been added yet.

Lack or reading or storing current state is why I developed a PowerShell scripting interface using the API (and why Just Macros existed).
I often want to check the current state of a key or even transition mode. This lets me do lots of "toggl" functions that can also return things like program source to what the were before the macro runs.

Example enabling a moving PiP that only requires on button to toggle on or off (lots of other cool stuff I use to set the flying key and crop parameters in PowerShell rather than relying on importing saved settings from ATEM Software).

Code: Select all

function ToggleRight3rd(){
   #save surrent transition mode and set to mix
    $Global:TxMode = $me[1].TransitionStyle; $me[1].TransitionStyle = "Mix"

    if($Global:ME2USK2.OnAir -eq 1){
        #fly to full screen

        $Global:ME2USK2.FlyRunToKeyFrame = [SwitcherLib.enumFlyKeyFrameDestination]::FlyKeyFrameFull
        start-sleep 1
        # change camera used here and up in declaration $Global:ME2USK2.InputFill = 1
        $me[1].Program = 2
        $Global:ME2USK2.OnAir = 0
    }
    else{
        $Global:ME2USK2.FlyRunToKeyFrame = [SwitcherLib.enumFlyKeyFrameDestination]::FlyKeyFrameFull
        $Global:ME2USK2.OnAir = 1
        $me[1].Program = 10 #Graphics source
        $Global:ME2USK2.FlyRunToKeyFrame = [SwitcherLib.enumFlyKeyFrameDestination]::FlyKeyFrameA
    }
    #return transition mode
    $me[1].TransitionStyle = $Global:TxMode
}