Designing a live event setup with Ruby, Power Core and RƎLAY

A live stage mix must serve performers, presenters, front-of-house engineers and any broadcast feed without becoming one fragile chain. The design should separate local audio, control and monitoring, then define what happens when a network path, power supply or operator disappears.

Ruby provides the performance-focused mixing environment, Power Core handles networked audio at the edges, and RƎLAY supports approved remote control and monitoring. This division keeps critical sound close to the stage while giving touring teams a controlled way to participate from elsewhere.

Build a show-ready signal map

Begin with a show-ready signal map, not a console layout. List microphones, instruments, playback, talkback and communications, then identify every feed needed by monitors, in-ear systems, the PA, recording or broadcast. Give each route an owner, a stable name and a clear emergency-mute state.

Keep the map visible to the people who patch, operate and troubleshoot it. A habit of showing customers everything gives crew, suppliers and stakeholders a shared view of the intended flow, reducing disputes when a feed is missing or a cue lands late.

Keep critical audio local

Use Power Core at stage boxes, in the orchestra pit or beside remote I/O to turn analogue and digital sources into consistent networked audio. Position units so short, labelled connections reach the sources, while processing and gain trimming happen before signals travel toward Ruby.

At front of house, Ruby should receive primary and alternate streams over physically diverse paths where the venue allows. Keep the stage mix on the local network, use redundant network and power options, and provide a known fallback mix if connectivity fails.

Shape Ruby around performance cues

Ruby should balance the room, programme feed and performer sends without sending every cue on every output. Separate talkback, sound reinforcement and broadcast returns, then set clear limits and priority rules for sources that can overload a stage monitor or broadcast feed.

Build snapshots around completed show states: doors open, band walk-on, speech, performance and end of show. Include the relevant mutes, sends and processing in each state, while retaining an engineer’s physical override for an unplanned walk-on or emergency announcement.

Add RƎLAY as a remote operations layer

RƎLAY is suited to authorised off-site control and monitoring, such as a producer checking a broadcast feed or a second engineer reviewing scene changes. Keep the main stage and monitor mixes on the venue LAN, restrict accounts and use the WAN for control or monitoring traffic that has a tested fallback.

Lawo's explanation of automatic console snapshots shows how VisTool Scripting can trigger dependable states during commercial breaks. The same guarded logic can cue clean changes for a hybrid live event, provided each trigger is confirmed against the actual show state and a manual recall remains available.

Automate predictable changes

Automation should remove repetitive actions, not judgement. Use named scenes, bounded changes and show-speed rehearsals, while keeping a physical bypass so a failed recall cannot silence the room or remove a performer feed. Log each recall during soundcheck and investigate anything outside its expected sequence.

For a panel discussion, automatic microphone control can keep several voices intelligible without forcing the host to ride every fader. Lawo's account of multi-microphone panel mixing explains the practical value of AutoMix; tailor its hold time and behaviour to the room, presenter cadence and local accents rather than assuming a visiting engineer’s defaults.

Rehearse for Australian operating conditions

In Sydney or Melbourne, an arena load-in can sit behind a long patching window, while outdoor stages face wind, rain and changing audience noise. Crews may call a quick update a “shout” and schedule the load-in for the “arvo”; place those cues in the rehearsal brief and document them plainly for casual and relief crew.

An Australian tour can combine equipment freighted between states with locally hired crew, so responsibility can change from city to city. Check 230 V, 50 Hz supplies, isolate faults and rehearse RƎLAY loss over the production carrier rather than public venue Wi-Fi; an unreliable WAN path must never become the show's lifeline.

Separate control, transport and monitoring

Ruby's console and snapshots control the mix, Power Core moves audio between distributed sources and destinations, and RƎLAY extends selected control or monitoring views. VisTool Scripting and AutoMix can simplify operations around those jobs, but they should remain supporting tools rather than substitutes for a stable manual workflow.

That separation makes faults easier to diagnose. It also lets a crew keep the show running locally while a remote user loses access, rather than making every layer depend on the same connection or application.

Component	Core function	Best position	Design safeguard
Ruby	Live mixing, sends and scene recall	Front-of-house control position	Physical control, safe mute states and local fallback
Power Core	Audio I/O, conversion and networked transport	Stage box, pit or remote I/O	Redundant network, power and labelled patching
RƎLAY	Authorised remote control and monitoring	Production office or approved off-site venue	Restricted access; keep critical audio on the local network

Treat the console, I/O and remote-access layer as one system during commissioning, then give each an operational fallback. Record who can change mutes, sends and snapshots, and rehearse those handovers with show staff.

The practical takeaway is to keep the stage mix operable at the venue, make network and power failures recoverable, and leave the crew with one rehearsed route back to a safe, intelligible show mix.