A single lighting console operator managing a 500-fixture intelligent rig through a 3-hour show with 400 cues, real-time request changes, and a director who has developed strong opinions about what ‘warmer’ means is operating at the cognitive and physical limits of a single human’s bandwidth. The dual operator console configuration) — where two engineers share control of the lighting system through a single console network — is the professional response to this limitation, and it is standard practice on major touring productions, broadcast events, and large corporate shows where the complexity genuinely exceeds single-operator management capacity. Building a dual-operator system correctly, however, requires more than connecting a second surface to the network. It requires deliberate design of the control architecture), clear definition of operational boundaries, and pre-show communication discipline between operators that transforms two individuals into a coordinated system.
Network Console Sharing: How It Works
Modern professional lighting consoles — grandMA3), Hog 4), ETC Eos) — all support multi-console network operation) through their proprietary network protocols (MA-Net3, HogNet, and ETC Net respectively). In these systems, multiple consoles on the same network share a single show file) and a common output state — any cue executed on any console affects the entire rig simultaneously. grandMA3) supports up to 10 control nodes in a full configuration; Hog 4) allows up to 32 consoles in a single session; ETC Eos) supports multi-console via Client/Server architecture). The surface type can vary — a grandMA3 full-size) as the primary console paired with a grandMA3 light) or MA3 Wing) for the second operator — allowing the second station to be positioned differently in the venue based on operational requirements (FOH for primary, side stage for followspot operator, for example).
Defining Operational Boundaries
Without clearly defined operational boundaries), a dual-operator configuration devolves into competing control of the same fixtures — one operator’s change overwriting another’s within milliseconds. The standard approach is executor ownership) — assigning specific executor pages, masters, and playback buttons to each operator, so that Operator 1 owns the position, beam, and dynamics layers) while Operator 2 owns colour, atmosphere, and specials). In grandMA3), this can be formalized through user profiles) that control which executors each operator has write access to. Alternatively, the system can be divided by fixture group) — Operator 1 controls the overhead rig), Operator 2 controls the floor and side positions) — a split that works well for shows where the creative direction of each rig layer is genuinely independent.
Primary/Secondary Designation and Authority Management
In any dual-operator configuration, there must be a designated primary operator) with ultimate authority over the show state. The primary operator — typically the LD or the most experienced operator on the call — has responsibility for final cue execution) and the authority to override or countermand) any action by the secondary operator. This authority structure must be explicit and agreed before the show begins. In grandMA3), the session priority) setting establishes which console’s commands take precedence in simultaneous operations — a critical setting that must be verified as part of the dual-console checkout. In Hog 4), the master/slave designation) serves the same function. The secondary operator must be briefed on the precise meaning of their role: not a co-equal decision maker but a technical execution partner) who extends the primary operator’s capability without conflicting with their creative authority.
Communication Between Operators
The communication channel between the two operators during the show is as important as the technical configuration. Most dual-operator setups run the two operators on a private intercom channel) separate from the main show intercom — allowing them to communicate about console actions without broadcasting to the entire crew. The communication discipline required is similar to a flight deck crew resource management model) — explicit callouts before significant actions (‘going to scene 45,’ ‘holding atmosphere layer,’ ‘bringing colour to 60%’), acknowledgment confirmation) from the other operator, and a clear conflict escalation procedure) when both operators reach for the same control simultaneously. Dual-operator systems that operate without this explicit communication discipline produce more conflicts and show errors than single-operator systems, negating the complexity benefit they were deployed to provide.
History: From Single Operator Boards to Networked Systems
The concept of multiple operators sharing a lighting control system dates to the manual preset boards) of 1960s theatrical production, where multiple dimmers) were physically divided between operators at separate sections of a long analogue board. The introduction of computer memory consoles) in the 1970s — the Strand Light Palette) (1974) and the Kliegl Bros. Command Performance) — initially reduced this to single-console operation, as all control was centralized in the computing element. The network console era), beginning with Flying Pig Systems) (now Hog) network architecture in the 1990s, reintroduced multi-operator capability at a higher level of sophistication — allowing consoles to share state dynamically over Ethernet rather than requiring physical control surface division. Today’s multi-console architectures are the mature evolution of this approach, refined through three decades of live event deployments.
