Building for Cues

Originally posted to LinkedIn

The way media servers are cued has some important things in common with the linear editors in the past. Screen content creators usually use only non-linear timelines and may not consider the exact needs of the live cueing process. And might try to implement aspects of the post-production workflow that may or may not be helpful.

A live event will almost certainly never want a 2-pop, slate, or leading handles in any delivered clip. These usually offer little towards proper sync on a media server. And generally make for extra work in trimming these to get to the actual cue point.

With few exceptions, an individual file’s action should begin as if pushing a button launches it to the audience. Because chances are that’s what will happen.

If you’re on a Mac, you can imagine it like the Quick Look function when you press the spacebar with a file selected in the OS. You press the button, you see the clip. [On Windows you can download a plugin with the same name that does the same thing].

If the content is for a musical performance, that cue point probably wants to be timed precisely to a drum downbeat. If timecode and click-tracks are involved, the head of the file might be less important as the cueing and time-sync are a bit more automatic.

Unlike the clip head, you’re almost always going to want an extended trailing end to the clip (loop, hold, or continue action). Ten seconds is often considered a safe amount of time.

There are plenty of exceptions, and most media servers are capable of trimming off unnecessary clip leaders. But time spent making these kinds of adjustments is time that could be spent doing many other tasks on the list before a show is set to begin.

Almost every live event in the world is assembled under some amount of duress. The more that a content creator can do to simplify things for the show programmer, the smoother everything can go.

Tiny adjustments add up to large amounts of time. Especially if clips need to be revised and redelivered.