Frequently asked questions
- Mixing musical theatre
- Using X32 Theatre Control
Why do I need to turn microphones on and off so often during a musical theatre show? This seems more difficult than mixing a band.
A musical theatre show is quite different to a live band performance: each genre has distinct requirements that are best served by different workflows. When live music is reinforced, unidirectional microphones are typically used and placed as close as possible to each instrument – isolating the microphone from other sound sources. However, in musical theatre the actors are typically wearing sensitive omnidirectional microphones on their heads – these pick up a lot of ambient sound, including the sound of other actors speaking.
When the sound of an actor's voice is picked up by several microphones in close proximity and then mixed together through an audio console, it can result in a degraded sound quality from these interactions. For this reason, the best practice in theatrical mixing is to only have a mic up when it's in use – just when the actor is speaking or singing. By ensuring that mics are only on when they are in use, we help the audience focus on whomever is currently speaking or singing, which ultimately keeps everyone immersed in the story.
Turning a mic down when an actor is not speaking or singing helps reduce or eliminate these undesirable interactions between microphones, reduces overall noise in the mix, and removes noise from actors' mics that are not in the current scene and could be backstage (maybe talking or changing costumes!). In addition to all of this, reducing the number of open mics at any time maximises the sound system's gain before feedback.
The console has an inbuilt automixer. Can't I just use that? What about noise gates?
While automixers can be very helpful for panel talks and corporate audio applications, they're not particularly useful for musical theatre. Automixers can not understand the artistic or musical considerations of a theatre performance, such as judging the proper balance between lead and ensemble vocals, accommodating dynamics in performances, or anticipating an actor's delivery in the same way a human operator can, which is why automixers are not commonly used in professional musical theatre mixing.
A skilled theatrical sound operator will be able to react to and reinforce subtleties in an actor's performance, often accenting or de-emphasising particular words or even syllables. Noise gates are much simpler: they either open or close depending on the signal level, so they have no idea what they're reacting to, or what they should be reacting to. If the gate threshold is set high enough to shut out mic bleed from other nearby actors, it will not open for quiet or whispered passages. An actor coughing – or another loud noise happening on stage – can open all of the mics at once, and gates aren't smart enough to deal with a situation where two actors are speaking face-to-face, where a human operator would choose one microphone and leave the other turned down.
In addition, the "chopping" sound of a gate opening or closing can be quite noticeable, particularly during quiet moments of a show.
Why not just program channel mutes for every entrance and exit? Or leave the DCA faders up all of the time?
Simply put, because it doesn't work very well. Any sudden volume changes draw the audience's attention to the sound system and out of the world of the story. Apart from potentially clipping off lines when mutes are snapped on and off, the abrupt changes in the noise floor sound quite objectionable, whereas a moving fader is much more forgiving. Since actors are humans (we think...), their performances will vary slightly from night to night, and fader moves allow the operator to adapt to these subtle variations – rather than just slamming mics open when actors enter the stage.
Actors have a dynamic vocal range and won't say (or sing) each of their lines at the same level throughout the show, so some fader adjustments are always going to be required. The level that the actor is delivering, and the level that is artistically appropriate at a certain point in the show, will change constantly – sometimes within a line, or even within a word. In musicals there is also a large difference between the amount of reinforcement required for dialogue compared to musical numbers, and within musical numbers the level of an actor's mic can change dramatically as the song progresses (e.g. solo singing, chorus singing, dialogue with underscoring, more solo singing, etc).
A trained ear and level balancing ability are key skills of a good theatrical sound operator.
So I really should just move the DCA faders?
Yes! Mixing the show on DCAs (or VCAs / control groups) is the well-established best practice for musical theatre mixing.
This approach eliminates the issues discussed above and brings some great benefits as well – no unused mics open, maximised gain before feedback, no chopping or clipping lines, no abrupt shifts in the noise floor, and greatly reduced or eliminated interaction between mics (comb filtering, sometimes referred to as "phasing"). It allows the operator to react to the natural dynamics of the show and adjust for variations in performances.
It's also a lot more fun: the operator ends up "playing" the console like an instrument, it's a very tactile artistic feeling compared to mechanically firing a cue list. The operator is given room to continually improve the mix as they become more familiar with the show. Here are some videos demonstrating the technique.
Large musical theatre shows are usually mixed line-by-line – throwing a DCA fader up for every individual dialogue line and immediately pulling it down afterwards – to minimise the number of open mics. This can be difficult to achieve for smaller productions especially when actors skip lines or have inconsistent timing. When using headset mics in a high gain before feedback environment it's sometimes
possible to cheat and mix dialogue sections in blocks, essentially leaving the mics for characters on the current script page open rather than throwing every line. However it's always best to tightly mix the show whenever possible, particularly during musical numbers that require lead vocals to be balanced against ensemble vocals.
How many DCA assignment cues are in a typical musical?
It depends on the complexity of the show, the number of wireless microphones, and the amount of additional automation required, but it's common for a 2½ hour musical to contain 50 to 100 DCA assignment cues.
When planning out cues it can be useful to think in terms of French Scenes. Every character that speaks on stage will need to be assigned to a DCA in a cue, so a good starting point is to create cue points when several characters enter or leave the stage. These cue points can then be refined based on the dialogue flow in the script – some scenes may have lots of characters speaking necessitating multiple cues, others may not introduce any new speaking characters so no cue is required. Musical numbers usually require separate cues.
The general aim is to create just enough cues for the show: too many cues can result in excessive go button hits, not enough cues can result in lingering stale DCA assignments. The cues should be structured in a way that allows the operator to have the mics they need under their fingers at the correct time.
How should I order my DCAs?
There are two main schools of thought on this. The first is to keep the same characters consistently assigned to the same DCAs as often as possible, and the second is to assign DCAs in script order for each scene (first character to speak on 1, second to speak on 2, etc).
Maintaining consistent DCA assignments for each character helps ingrain a spatial mapping so fader throws become repeatable, it's also more reliable if the operator accidentally loses their place in the show and has to fall back to muscle memory. Characters are usually assigned to DCAs based on their importance in the show, i.e. the main lead gets 1, the next lead gets 2, etc. However this can be problematic in dialogue scenes with characters delivering lots of one-liners – the fader throws end up all over the place.
Assigning DCAs in script order can be useful for fast-paced dialogue – just throw the faders in order from left to right – but it has some drawbacks. It usually requires additional programming compared to the first method, it relies on the cast accurately reciting their lines in every performance, and there is no safety net if the operator accidentally loses their place in the show.
In general the first method (consistent assignments) is preferred most of the time, but the second method (script order) can be a useful tool when a show has a few busy dialogue scenes. Additionally, it helps to keep ensemble groups assigned to the right-most DCA faders – balancing leads against ensembles is much easier when the faders fall under separate hands.
Occasionally neither method works so a scene or musical number has to be programmed completely ad hoc... the rules can be bent where it makes sense!
Large consoles usually support 12 or more DCAs. How should I mix with just 8 DCAs?
Although it would certainly be nice to have more DCAs, on larger consoles DCA 11 and DCA 12 are typically used for band and reverbs, so ten DCAs or less end up being used for wireless microphones. Plus – we only have 10 fingers, so there are diminishing returns!
To allow all 8 DCAs to be used for wireless mics whilst maintaining control of band and reverb levels, X32TC can gang the band subgroup with the LR fader (see LR fader ganging feature guide
), and the console's user-assignable encoders can be configured to control reverb send buses.
For scenes with many solos, it might be helpful to compress ensemble members to a single DCA, or group several soloists together.
Should I have X32TC control all console channels?
Probably not. X32TC is designed to handle the complex frequent DCA assignment cues for wireless microphones, not all of the automation necessary for a show.
Typically, band channels don't change a lot during a show, so it's recommended that they not
be controlled by X32TC and instead assigned to a separate DCA or routed into a subgroup controlled by the LR fader ganging feature
. Small variations to individual band channels can be accommodated in console snippets and recalled from X32TC.
Playback channels are generally kept unmuted for the whole show and levels for individual cues are set in the playback software programming.
I don't like what X32TC does with scribble strip colours. Should I reset them myself?
Scribble strip colours are typically used to help identify and classify channels, which is a nice upgrade from the tape used on analogue consoles.
X32TC repurposes scribble strip colours for DCA fader signifiers and channel status indicators (channel monitoring / active channel highlighting
). These are very different design concepts to the static labelling they're traditionally used for: signifiers show at a glance what actions
can be performed on an object before it is used, and dynamic status indicators provide real-time feedback
of changes or issues. These enhance the console workflow for theatre mixing by helping the operator focus on what's important during a show.
For DCAs, the scribble strip colour indicates what will happen to the DCA when the next cue is fired, so the operator knows what to do with the fader before they hit go. The colour does not tell them what assigned to the DCA – this is left to the number and label, which can be better cross referenced to the script.
For channels, X32TC uses the "cattle, not pets" mindset. Scribble strip colours help the operator look for abnormalities in the herd rather than distinguish specific channels. The operator's focus during the show belongs with throwing the right DCA faders at the right times, not being distracted by combing through channels. If a channel goes bad or uses a non-standard profile X32TC will indicate it.
Hopefully this has convinced you of the utility of the X32TC scribble strip approach, but if not, you can disable channel monitoring and recall a snippet to override the colours.
I like panning ensemble groups wide because it sounds better. Why is panning controlled by position setup?
In theatre sound, panning and delay are generally used as tools to help the amplified sound reflect the physical movement of actors on stage. Although dramatic panning may sound nice at the mix position, we need to be mindful that the sound reinforcement should feel transparent to all of the audience.
Since the human hearing mechanism will typically localise a source towards the direction of its first arrival, and most of the audience is seated closer to one loudspeaker than the other, the majority of audience members will always localise sound towards their nearest loudspeaker. Panning can sometimes be effective in small amounts with certain system configurations, e.g. an LCR system with overlapping coverage, but it can not be relied upon for localisation and image control.
The intention of position setup in X32TC is to predefine the common acting areas so delay/pan can be easily assigned to actors' microphones during DCA cue programming, rather than manually recording individual values for each cue as with console scenes. A good workflow would be to define a handful of common positions (downstage, midstage, upstage, apron corners) along with any special positions determined by the set, program them into the DCA cues, then during bump in, mic up an assistant and measure the appropriate delay/pan values. The positions can then be updated in position setup and all of the cues will use the correct delays/pans for the venue (until the actors miss their marks!).
Further reading on the limitations of stereo in live sound:
I have multiple spare backup microphones. What's the best way to manage them all with X32TC?
It's generally better to double mic the lead actors who won't have time to get a new microphone fitted during the show. There is no point having lots of spare microphones if there is no time to fit them to actors between scenes.
For all other potential failures, a simple solution is to have a wireless handheld mic side stage that can be quickly passed to an actor. It's best to run this as a standard channel and not have X32TC control it due to differences in gain structure.
As a last resort you could have a single floating spare pack
to be ready in case of emergency, however the opportunities for a swap are often limited. It's better to spend time ruggedising lavalier and headset mics before the production rather than hope for good timing to fit spares during a show.
My show inputs won't fit on a single X32/M32 console. How should I manage this?
One option is to submix the band inputs on a separate console ("sidecar") and then send that mix to auxiliary inputs on the main X32/M32. This can be achieved using analogue patch leads, or by linking two X32/M32 consoles via their AES50 ports. When linking via AES50 it's best to set system clock from the main console – ensure the main console's clock is set to internal and the band console's clock is set to its AES50 port.
If you would like to recall scenes or snippets on the band console, consider using playback software to send OSC commands into the band console – the playback software cues could then be recalled from X32TC cues.
Will bad things happen if I edit cues while X32TC is running a show?
Cues fire independently of what you're editing. It might be a good idea to tell the operator not to be distracted by what's happening on the screen.
When editing is unlocked, double-click jump is disabled – hold down ⌘/Ctrl while double clicking on the cue to force jump.
How do I back up all of my show data?
When using X32TC the show data is split across two places: the X32TC file on computer and the base scene on the console (plus any snippets on the console).
To save the base console scene, jump to cue 0 in X32TC and then save the scene on the console as normal. The scene file can then be transferred to a USB flash drive (etc) as desired.
To restore a backup, disconnect X32TC, and load the console scene (check recall scope). Then, open the X32TC file, connect X32TC to the console, and hit go.
Can X32TC work with other consoles?
I would like to extend X32TC to other consoles but unfortunately manufacturers make this quite difficult.
X32/M32 consoles are the only ones in their class with a published comprehensive network control API. Other consoles have no documented API at all, or only provide access to very limited functions via legacy hardware interfaces. I also do not have access to other consoles for testing.
Until this situation improves I'm unable to extend X32TC to other consoles whilst keeping the application freely available.
Should I run X32TC on the same computer as...
X32TC is lightweight and can be run on the same computer as playback and other show critical software.
Does X32TC run on M1 Macs?
Yes (using Rosetta).
I have an older Mac that can't run macOS Sierra, can I still use X32TC?
I would really like to support older versions of macOS as there are a lot of old (but good) Macs out there that could run X32TC. However, in order to support newer macOS features Apple force me to use the latest SDK which in turn requires me to remove support for older OS versions. For now, I'm trying to stick with the SDK that has macOS Sierra as the minimum requirement – but with the introduction of Apple Silicon I may be forced to use a newer SDK soon.
The last version I built with an older macOS SDK is v2.7.1 – it will run on OS X Mavericks and later. Please contact me for a download link.
All third-party product names, logos, and trademarks are the property of their respective owners. Their use in this documentation is for identification purposes only and does not imply endorsement.