MULTILARM // FIELD NOTES
Performing Arts · Worked Example

House Open, Five Minutes, Beginners

Running a small theatre’s pre-show, interval and backstage audio · 7 min read

Illustrative worked example — a representative scenario showing how Multilarm is configured, not an account of a specific customer.

Theatre calls are a fixed ritual: thirty-minute call, fifteen, ten, five, beginners. They go out to different parts of the building — dressing rooms hear them all, the foyer only hears the showtime chime, the auditorium hears nothing until the house opens. A small venue doesn’t need the £40,000 show-relay system the West End uses. It needs one Multilarm box, a handful of USB dongles, and a show-specific XML.

The venue

A 180-seat receiving house, eight shows a week in season, a small permanent technical crew plus visiting stage management from each touring company. The building has a foyer bar, a 180-seat auditorium, three dressing rooms on two levels, a green room, and a wardrobe shop. Each space has an existing ceiling speaker tied to an old paging amplifier. The venue’s previous stage management workflow was the deputy stage manager (DSM) walking the building with a portable bell. That doesn’t scale to two shows a day.

Hardware

The calls

Each zone runs as its own Multilarm instance with a --config launch. The dressing-room instance (zones\dressing.xml) carries the TTS-spoken calls via TextData + TextToSpeech=True, with its eight absolute call times laid out in DateAndTimeData. A simplified excerpt for an evening show with a 19:30 curtain:

<MAConfig><InstanceName>Dressing rooms</InstanceName></MAConfig>
<MAConfig><PlaybackDevice>5</PlaybackDevice></MAConfig>
<MAConfig><TextToSpeech>True</TextToSpeech></MAConfig>
<MAConfig><TTSPath>{app}/TTS</TTSPath></MAConfig>
<MAConfig><TTSFileFormat>mp3</TTSFileFormat></MAConfig>
<MAConfig><TTSChimePath>{app}/Chime/softbell.mp3</TTSChimePath></MAConfig>
<MAConfig><RecurEveryDay>True</RecurEveryDay></MAConfig>
<MAConfig><TimeDelimiter>|</TimeDelimiter></MAConfig>
<MAConfig><TextDelimiter>|</TextDelimiter></MAConfig>
<MAConfig><DateAndTimeData>18:55|19:00|19:15|19:20|19:25</DateAndTimeData></MAConfig>
<MAConfig><TextData>Thirty-five-minute call. Thirty-five minutes please. Thank you.|Half-hour call. Half an hour please. Thank you.|Fifteen-minute call. Fifteen minutes please.|Ten-minute call. Ten minutes please.|Act one beginners to the stage please. Act one beginners.</TextData></MAConfig>

The foyer instance (zones\foyer.xml, PlaybackDevice=3) carries just the House open chime from its own folder; the auditorium instance (zones\aud.xml, PlaybackDevice=4) fires the two-minute settle chime. The DSM maintains one config per curtain time (dressing-1930.xml, dressing-1430.xml…) and selects the day’s variant with AlternateConfig date rules, or drops it in directly via the Web Remote’s live config editor. Because each variant differs only in DateAndTimeData, rewrites stay tiny.

Why the half-hour is louder than the five: a half-hour call is the first thing dressing rooms hear and it’s a wake-up. By beginners, the cast is in the wings — a softer call is enough. Multilarm handles this with VolumeProfileRules on the dressing-room instance, e.g. 18:50-19:10,volume=1.0;19:10-19:30,volume=0.65, so the same TTS voice is loud at 30′ and gentle at 5′. The same engine, zero changes to the pre-amp gain.

Interval chimes

The interval is triggered at the DSM’s discretion — never on a rigid clock, because the first act runs long or short. A dedicated Interval instance (zones\interval.xml, PlaybackDevice=3, MirrorDevices=4) exists purely to fan a chime out of the foyer and the auditorium simultaneously; its AlarmPath points at C:\Theatre\Interval\Chimes. The DSM opens that instance’s card on the Hub dashboard and taps Test Alarm three times: first chime at “five minutes until the second act,” second at “two minutes,” third at “please take your seats.”

Because the chimes are triggered on-demand, the DSM never has to edit a schedule mid-show. The scheduled engine handles the predictable pre-show calls; the Web Remote’s Test Alarm handles the flexible ones.

Backstage voice cues

When a quick-change assistant needs to be told the wig won’t fit and plan B is now, the old workflow was running down two flights of stairs. Now the DSM uses the Voice Broadcast card on their console PC:

  1. Hold Record, speak the cue.
  2. Tap Transmit, confirm.
  3. The message plays over the dressing-room and green-room speakers (device 5 only — wardrobe is on device 6, auditorium on 4).

The “zone-specific broadcast” is the important bit: a show-critical backstage message should never leak to the auditorium. Because Voice Broadcast transmits through the instance’s own PlaybackDevice, the DSM selecting the dressing-room card on the Hub dashboard before tapping Record hard-enforces that the recording never reaches the auditorium’s output.

Show-stop and evacuation

A dedicated Alerts instance (zones\alerts.xml) owns the venue’s evacuation announcement — pre-recorded by the venue manager, tone-checked, approved by the fire officer. Its config mirrors to every other device so one press reaches the whole building:

<MAConfig><InstanceName>Alerts</InstanceName></MAConfig>
<MAConfig><PlaybackDevice>3</PlaybackDevice></MAConfig>
<MAConfig><MirrorDevices>4|5|6</MirrorDevices></MAConfig>
<MAConfig><AlarmPath>C:\Theatre\Alerts\Evacuation</AlarmPath></MAConfig>
<MAConfig><AlarmFileFormat>mp3</AlarmFileFormat></MAConfig>

The house manager’s phone bookmarks this instance’s Web Remote URL; one tap on Test Alarm plays the evacuation file on foyer, auditorium, dressing rooms and wardrobe simultaneously. No mis-dialled device indices because the mirror group is pinned in the config, and every fire is appended to Multilarm.playlist.log with a timestamp the house manager includes in the incident report.

Touring companies and AlternateConfig

Each visiting company gets its own config file variant for the show’s specific call times, cast-specific beginners call, and anything else that changes from production to production. A tour week’s worth of configs might look like:

The DSM either edits AlternateConfig to map dates to files, or drops the chosen file directly into Multilarm.config.xml via the Web Remote live editor. Hot-reload picks up the swap on the next tick. The active config filename is printed top-right of the dashboard — a “did I remember to flip it?” sanity check you can see from across the booth.

Monitoring from the production office

Touring production managers rarely stay in the booth. With the Cloud Relay turned on, their phone dashboard shows playing, alarmInfo (which call most recently fired, in which folder), volumeProfile (any cap applied) and uptime (has the booth PC rebooted unexpectedly?) — updated every 30 seconds. When they walk back into the venue they already know whether the calls went out, and if not, which one was missed.

Takeaways

Theatre calls are one of the oldest automation problems in the business. One self-contained binary, four dongles and an XML. Try Multilarm on your next show week.