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. It was imperative that the zoom instance into which we fed Nigel’s video and audio was also the zoom instance from which we took the audio of the audience – this way we could utilize zoom’s audio processing to our advantage and avoid any of Nigel coming back into our feedīy close mic’ing Nigel we could have enough audio coming back into the room for Nigel to hear the audience, while zoom was clever enough to cancel that sound out of the feed that went back into zoom.My dislike is not for timecode in and of itself. This allowed control of a zoom client with OSC and which exposes certain information about the Zoom call back over OSC – this was a lifesaver as you will see below. Meaning that we would need to find a solution to ensure the audience are properly briefedĪ very lucky circumstance happened which solved many of these issues when a friend introduced me to Andy Carluccio of Liminal who it transpired had been working on a zoom implementation. The host has only limited control over what the audience see – without the audience’s input they may see a gallery view of every other participant, or they may get a big view of the show along with a thumbnail strip of the other participants – which we wanted to avoid. Zoom messes with the audio, even when you tell it not to - meaning that background sound effects can disappear or sound strange
Zoom only shows you one person's video at a time, or everyone in the gallery together, making it difficult to extract different people at the same time Zoom has limited “batch” features, meaning that things that are simple for one user – such as unmuting their audio, become complicated when you need to unmute 20 people very quickly
0 kommentar(er)
