An MSC GO is a GO, but it's up to you if you want the same action to be called "start" or "go" or "play" or "fire" in your OSC-handling device. I don't "like" OSC because it is one-to-one not one-to-many, can't be paralleled, and crucially is not remotely standardised. This was meant to be throwaway, and I thought I'd buttoned the discussion up with "a sequence of fixed duration" to cover use cases in any medium where time code is relevant, regardless of how you wish to categorise that medium (or if you want to use that same word to describe the buildings you practise that medium in). Half of your possible choices won't fire at all…ġ: The nature of theatre. Is QLab capable of interpolating the missing positional information on the intermediate frames and deducing the correct timing from the ongoing messages? If not then it will presumably take 2 frames to reconstruct the trigger code so cues will always be late – as if you were using OSC but having to wait 80ms (PAL) for the whole message to arrive. 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. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |