Who Owns Timecode When disguise Is in the Rig?
A media server with its own transport changes the master question. When disguise should own the clock, when it should chase, and how to draw the seam.
CueSync TeamStage Automation Engineers
A Media Server Is Not Just Another Follower
Most timecode discussions treat every device downstream of the master as equivalent: something that receives a position and acts on it. disguise breaks that assumption, because it has its own transport. It knows where it is in its own timeline, independently, and it is perfectly capable of being the authority.
That makes it a candidate for master rather than merely a consumer — and it means the master question has to be answered deliberately rather than by default.
When disguise Should Own the Clock
When the video is the spine. A content-driven concert where the visuals define the structure. A permanent installation. An immersive piece where the audience experience is fundamentally the video and everything else decorates it.
In those cases disguise already owns the authoritative timeline, and having it generate the clock removes an entire negotiation. Lighting chases. Sound chases. There is one transport and it is the one that matters.
When It Cannot Be
When the show is performed rather than played back. A band. A DJ. Any passage that is improvised, extended, or dependent on an actor being in place.
Here disguise has a transport, but its position no longer describes the show — it describes what disguise is playing. Those are the same thing right up until the moment a musician extends a passage, and then they are not. A video server confidently reporting a position the performance has left behind is worse than a server admitting it does not know.
The Failure Mode Specific to Video
The generic two-masters problem applies, but video makes it visible in a way lighting does not.
A lighting cue landing half a second late reads as a slightly loose show. A video section landing half a second late reads as broken. Audiences forgive the first and never fail to notice the second.
That visibility is genuinely useful — it means the fault gets caught in rehearsal rather than tolerated for a run — but the underlying architecture problem is identical: two authorities on show position, no tiebreaker, and disagreement the first time anything restarts.
The rig to avoid is the one where disguise masters video, a console masters lighting, and nobody has drawn the seam between them.
Frame Rate Is a Rendering Property Here
Worth separating from the general timecode advice, because the consequence is different in kind.
For a lighting console, a mismatched rate produces drift: gradual, survivable for a scene, embarrassing by the end of an act.
For a media server, a mismatched rate can produce artefacts: judder, dropped or repeated frames, audio-visual sync error. Not a gradual divergence — an immediately visible defect.
So declare the rate explicitly on every device and verify on the server itself. "It probably inherited it" is a reasonable gamble on a lighting desk and a bad one on a video rig.
Driving disguise When It Is Following
When disguise is the follower rather than the master, CueSync drives it over OSC — transport control and section jumps, beat-aligned, without an operator on the GO.
Section jumps are the interesting one. A show that must move to a different content section based on what the music actually did — rather than at a fixed wall-clock position — cannot be expressed as a timeline, and this is the case where deriving position from the performance earns its place.
CueSync also generates MTC, LTC, Art-Net timecode and TCNet outward, so on a hybrid show it can derive position from a live performance and hand disguise a completely ordinary clock to chase. From the server's point of view nothing unusual is happening, which is the correct outcome.
Compatible systems: disguise gx 3, gx 2c, vx 4, vx 2, rx II, and disguise Designer software.
Drawing the Seam
On a show that is partly played back and partly performed:
- Name the master per segment. Written down, not agreed verbally at the production meeting.
- Make the handover visible. The operator must be able to see which system is in charge and force the changeover.
- Never overlap. One master at a time. The seam is a point, not a region.
- Rehearse the changeover at least once with everyone present, because it is the moment where a misunderstanding between departments becomes a visible failure.
Further Reading
- Where Should Your Show's Timecode Come From? — the four architectures
- QLab or GrandMA3: Which One Should Be Master? — the same decision, lighting side
- How to Chase External Timecode with a Cue Stack — the follower's half
- disguise Integration — OSC transport, sections, compatibility
Frequently Asked Questions
It should when the video is the spine of the show — a heavily content-driven concert, a permanent installation, an immersive piece where the visuals define the timeline and everything else decorates it. In those cases disguise already owns the authoritative transport, and having it generate the clock removes a negotiation. It should not be master when the show is performed rather than played back, because then there is no transport whose position describes the room, and a video server confidently reporting a position the performance has left behind is worse than useless.
Keep Reading
Where Should Your Show's Timecode Come From?
Reaper, QLab, the console's internal clock, a hardware generator, or the live performance itself. Four architectures, and how to pick between them.
ReadQLab or GrandMA3: Which One Should Be Master?
Two systems that both want to own the show clock. How to decide which is authoritative, and why the wrong answer only shows up under pressure.
ReadHow to Chase External Timecode with a Cue Stack
Most guides cover generating timecode. Following someone else's is the harder half — locating, re-syncing, and deciding what happens when it stops.
Read