controlgeek.net/Timberspring Orlando 2019 Time Code Geekout Wrapup!

After taking 2018 off, Jim Janninck’s and my geekout during Infocomm was back and better than ever for 2019! (Coverage of past geekouts here). This year, Jim and I decided—instead of doing the traditional case studies we’ve done for many years—to address the issue of time code and the way it’s being used these days on live shows, which seems to be in the show control zeitgeist these days. Alcorn McBride generously offered us their brand new building with a great conference room and open tiki bar (!), and Medialon (which announced at the show its sale from Barco to a new company allied with 7th sense) helped out sponsoring some great food. Having competitors collaborate like this really exemplifies the spirit of the event—we’re all friends and geeks in the end.

First, a bit of background on time code to set the stage. Here’s a couple paragraphs from my book on time code’s background; I also have a free video on the subject here.:

Time code is one of the most widely used synchronization tools in show control, since it is easy to use, allows precise synchronization between multiple systems, accurate repeatability, and makes for straightforward programming of time-based systems. Society of Motion Picture and Television Engineers Time Code (SMPTE TC) was created first, and then MIDI Time Code (MTC) was developed to transport SMPTE time code over a MIDI link. While SMPTE (pronounced “sim-tee”) TC is encoded using analog audio frequencies and MTC is digital, they share many common aspects, so we will cover the basics of time code first, and then get into specifics of each type. As of this writing, the latest version of the SMPTE standard is ST 12-1:2014 - Time and Control Code. MTC was first released by the MIDI Manufacturer’s Association (MMA) in 1986, and consolidated into the overall, unified MIDI standards document in 1996.

TIME CODE BASICS

TC has its origins in videotape editing, so it breaks time down into hours, minutes, seconds, and frames; up to 24 hours worth of frames can be encoded, although it’s important to remember that the TC signal is its own clock, and does not necessarily match real time of day. One discrete TC “address” exists for every frame on an encoded media—a typical address might be 05:20:31:18, or five hours, 20 minutes, 31 seconds, and 18 frames. Time code can be recorded on a wide variety of media and systems, and TC is absolute: If time code for a show starts at 08:00:00:00 and the tape is fast forwarded to 08:18:01:15, the system can quickly determine that this frame is 18 minutes, 1 seconds, and 15 frames from the beginning of the show.

So time code was developed by the film and video industry decades ago, and we used it originally for its intended purpose—synchronizing linear media like audio and video tapes. However, over the years and with the development of powerful digital playback systems with accurate internal clocks, that linear synchronization use case has become less necessary for us, while another application has arisen: triggering events based on a show clock. These events might be lighting cues, pyro, sound cues, motion control—pretty much anything on a show. In addition, since these days we are often running ethernet to connect our systems, we less and less want to run old school XLR’s or MIDI cables to distribute SMPTE or MIDI Time Code. But since so much show gear has a SMPTE LTC input these days we’re often running a network cable for control and an XLR for time code. And time code or a show clock in some form is used on a huge number of shows these days.

So in many ways, we’re at a bit of a crossroads in our industry, with so many shows needing a show clock, but so many using a very old technology that works very well but is distributed over a very inconvenient format And the video production industry too has been affected by the same forces; they now have a bewildering array of frame rates of media created on a huge variety of devices. But in their world, the desire for a “digital birth certificate” is strong, while the day to day show clock requirements of our world aren’t as much of an issue. SMPTE has been assessing the market for several years, and centering development under a banner of “TLX”; they have a webcast explaining that effort here.

So all of this led to a very spirited discussion, and—thanks to Steve Milner of the great Youtube channel and podcast DC Sound Op—you can watch or listen to our entire discussion here!

It was a fascinating and very geeky discussion, but I came away with several useful takeaways.

Transmitting SMPTE Time Code Signals over a Network Today

Several approaches to send LTC currently in use were discussed:

• QSys: It’s possible to send LTC using UDP and ASCII inside a QSC QSys network.

• RTP MIDI: It’s also possible to send MTC over a network using RTP over systems like Medialon or KISS Box.

• Beckhoff: It’s possible to convert LTC to RS232 and send it over a Beckhoff network.

• OSC: Apparently there is a way to send time code over OSC

July 5, 2019: Update: From Mitch, Director of Technology at Smart Monkeys, describing what they are doing:

It’s very simple: we send out unicast/broadcast UDP packets formatted like “hh:mm:ss/ff0x0d” and then the receiver just takes it and tries to skew to it. We’ve had sources be an LTC->Serial(http://www.adrielec.com/aec-ubox.htm)->Moxa, Q-SYS, and Medialon. Destinations have been Q-SYS and Medialon. We’ve had no real problem with accuracy as the networks are usually <3ms latency.

While these approaches are good work arounds with the existing technologies, to me, none of these approaches are all that elegant, and ideally a simple multi-castable network system would be a lot more desirable.

Synchronization

One big part of the session was a fascinating discussion about the differences between frame rate/show clock and underlying sync accuracy. For a variety of applications we need to maintain timing precision across the network; most seemed to think that that PTP does that pretty well. So that sets the underlying timing accuracy of the systems, but we really didn’t seem to come to any consensus on how to resolve that underlying clock to a show cue clock, frame rate, etc. Of course using PTP and NTP it would be possible to schedule cues dynamically and transmit them with some sort of offset from time of day clock, but that’s a pretty sophisticated approach that, in my opinion, would be hard to standardize and wouldn’t be really desirable for dynamically changing live shows. So there’s definitely something to explore in this issue, but right now it feels so broad that I don’t even know how to put my finger on it. It might be a good topic for a future geekout.

Wish List For a Network Time Code Standard

Towards the end of the session, I tried to get the consensus of the group to create a “wish list” for a network time code standard for live show applications. What interesting, is that—unlike some other older protocols (like DMX)—the frame information sent over LTC is really fine for most of our applications today (we could probably argue about a frame rate) and doesn’t really need to be changed. All we need is a way to cleanly and easily transport the existing information over a network. We came up with this wish list (subject to my interpretation):

• Base the system on Ethernet, IP, and UDP (this makes it layer 3 which is desirable)

• Allow either multicast or broadcast—"reliability" in the IT sense (TCP) isn’t that important for our applications. A dropped frame will be overwritten quickly by the next one.

• Use only simple and minimal overhead (don't include unnecessary check sums, etc)

• Make the standard profile as lightweight as possible

• I didn’t put this on the list that day, but it seemed to me that the consensus of the group was that the latency of closed ethernet is probably good enough accuracy for event triggering (I say that because no one really proposed anything like AVB/TSN), and underlying precision, if necessary, could be provided by PTP.

From my reading of the current SMPTE TLX effort, it seems they have been heading toward a much more complicated approach that we don’t really need, and that complexity would likely inhibit adoption in our market. So my prediction for the next few years is that we will continue to use a variety of Rube Goldberg, ad hoc approaches to distribute old-school SMPTE LTC via networks to XLR cables for the last meter, and we’ll hope that the new TLX will evolve to meet our purposes. If not, we might want to look at developing our own, simple standard for the future. The knowledge demonstrated by the attendees in the geekout room alone prove that we certainly have the expertise to do so.

So all in all it was a great session,. and thanks so much to Steve for capturing it and doing all the work needed to edit such a freewheeling session! And special thanks to Loren Barrows from Alcorn and Eric Cantrell from Medialon for their ongoing support.

Jim and I haven’t thought about what to do during Infocomm in Vegas next year—if you have a line on a meeting spot please let us know!