As MTC takes 2 frames to send the positional reference for a single frame it clearly can't send every single trigger code available – only every other trigger code. There's no "sync" or "following" or "chasing" there is merely "triggering" when the precise control code arrives on that trigger input. It can take positional information from time code and use that to trigger cues, but in use this is actually no more sophisticated than taking pitch information from a MIDI input or time of day from the system clock to trigger cues. QLab can not be a "slave" because it can not delegate its positional information to an external source. When that time comes, I have every expectation that folks will put it to terrific use, and I’ll be very glad for that! 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.
0 Comments
Leave a Reply. |