For this reason, I can quite honestly say that I agree with you that QLab should be able to sync to timecode, and we do indeed plan to add that capability to QLab when we are able. Now I will conclude with some good news: while QLab was originally created for live theater, we are beyond delighted that it has been embraced by artists and technicians of all kinds. Therefore, for live theater I much prefer event-based show control, where a human person (usually the stage manager) can feel the live tempo of the show and cause design and technical elements to follow that tempo. Anything which we do that presses against that truth needs to be considered carefully, and avoided unless necessary. But the time between two events in a play is usually different every time the show runs. The amount of time that elapses between two events in a film are necessarily the same every time you view the film, so it makes perfect sense to use timecode as a tool in the production of the film. But on stage, time need not be so rigid, and trying to make it so removes some of its power and its beauty. When you are working on a film, television show, or live broadcast on a public schedule, this is exactly what you need. The whole point of timecode is that it is rigid and inflexible one frame is exactly one frame. The final and most significant cause of my dislike of timecode as used in live theater is that fundamentally, the very concept of timecode is antithetical to the core truth of live theater. While it doesn’t often cause problems, particularly in established workflows, it nevertheless hangs around, occasionally causing confusion and wasting time. Second: Drop-frame formats are a rather mathematically elegant but technically aggravating solution to problems which only still exist because we’ve grown so accustomed to using drop-frame formats. When the purpose of timecode is perfect sync, 1/6 of a second feels like a gigantic margin of error. It’s like a conductor reading measure numbers: “ONE two three four, TWO two three four, THREE two three four…” it’s fine in principle, but in practice what it means is that at 24 frames per second, a device following MTC might be as much as 1/6 of a second off. For those who don’t know, that means that four frames of MTC must be read before the receiving device knows exactly what frame we’re on. My dislike is for exactly three aspects of timecode:įirst: MIDI timecode, because it must exist within the technical limitations MIDI which are objectively very restrictive by modern standards, uses a quarter-frame format. My dislike is not for timecode in and of itself.