When automating your show, timing is everything. Whether you’re playing media, triggering graphics, switching inputs, executing macros,... - each action needs to happen not just in the right order, but also at the right moment. By introducing controlled 'delays', you gain precision and peace of mind in your show control.

Delays in Automator are measured in milliseconds and defined for each automation action. Delays can be 'static' or 'dynamic', we'll explain both below.

Delays in Automator are absolute, not relative. This means the delay timer of an action starts at zero when the automation is triggered, not based on the completion of the previous action(s) in the same section.

As a result, the example configuration below does not mean that the third action happens only once the second action's 100ms delay has passed, but the third action happens 300ms from zero - just like the second action happens 100ms from zero, and so on.

Zero being the moment a Block/Step button/CuezDeck button/... is triggered.

When e.g. playing a clip on vMix via Automator, in the example below using List inputs, we can add delays to the different automation actions to ensure them happening in the correct order.

In the example below, we see four different actions, each with a different delay, ensuring each to be triggered in the desired order.

Even though the example above also ensures the actions happening at the right time, we will give a different example to further explain.

In the example below, we will focus on the final two automation actions:

Here we see the delays being used to make sure that we automatically take out the Lower Third overlay/composition 3000ms (3 seconds) after it was triggered. This allows us to, with a single click, bring in the Lower Third and automatically have it go out again a certain delay later.

In short:

Both example we have seen in this article so far, are static delays. This means that each time the automation is triggered, the set delays remain the same and will be executed as such. This applies to every instance of the Cue Block using that automation.

Static delays are entered directly in the automation actions in Automator.

While static delays are powerful, sometimes you need a bit more flexibility. Different instances of the same Cue Block, with the same automation actions, may need different delays depending on the content, source, or context. This is where dynamic delays come in.

Dynamic delays use a value coming from a 'Plain text' field of the Cue Block that is being automated. So, unlike the example above where a value was manually entered in the automation action itself, a dynamic delay will take its value from what was entered in the corresponding field in Cuez itself.

Example of a Lower Third Cue Block in Cuez itself, with a plain text field for the 'IN' value, as well as one for the 'OUT' value to be used for our lower third animations:

Example of the same Cue Block, now in Automator, using the values of these fields as the dynamic delay:

The examples above mean that, according to the values entered in Cuez itself, the lower third would be brought in 3000ms (3 seconds) after being triggered, and would be taken out 6000ms (6 seconds) after being triggered.

You can combine static and dynamic delays in the same automations, meaning that you can have certain automations actions use a static value, while others use a dynamic value, allowing for a flexibility where needed.