Migrating from Lawo Zirkon to Ruby with confidence
Moving from a Lawo Zirkon console to Ruby is more than replacing one control surface with another. It is a transition from a traditional console-centered workflow to a software-defined, networked production environment. The change can bring greater flexibility, remote operation, and easier expansion, provided the migration is planned around real studio operations.
Ruby combines a familiar radio-console experience with IP-based infrastructure, configurable control, and centralized processing. Depending on the installation, the system may include Power Core audio nodes, VisTool interfaces, RƎLAY tools, and AutoMix capabilities. This creates new possibilities, but it also means that signal paths, user permissions, monitoring, and redundancy must be documented carefully.
A successful project begins with a clear picture of the Zirkon installation as it exists today. Record every source, bus, monitor feed, GPIO event, mix-minus path, codec, playout connection, and presenter workflow before deciding how the new system should be configured.
What changes when Zirkon becomes Ruby
Zirkon is typically understood through its physical console and associated processing environment. Ruby retains the immediacy expected in radio production while separating control from core processing. That separation allows operators to work from different surfaces or software interfaces while the audio engine and routing remain managed within the network.
This approach changes the role of the console. A Ruby surface is still the main point of interaction for many operators, but it is part of a wider ecosystem rather than the entire system. Processing, routing, control logic, and user interfaces can be designed around several studios, remote positions, or virtualized workflows.
The migration should therefore preserve the operator’s essential habits while improving the underlying architecture. Fader layout, monitoring behavior, talkback, source naming, and on-air safeguards deserve as much attention as the hardware specification.
Start with an accurate Zirkon inventory
Build a source-and-destination register before selecting the final Ruby configuration. Include microphone inputs, studio devices, telephone systems, codecs, playout servers, contribution feeds, cleanfeeds, monitor speakers, and production destinations. Note whether each connection is analog, AES3, MADI, or already transported over IP.
Document every special function that may be overlooked during a like-for-like replacement. Examples include cough muting, guest talkback, external-start commands, red-light control, fader-start behavior, mix-minus feeds, and automatic monitor dimming. These details often determine whether a new studio feels reliable on its first day.
It is also useful to capture current presets and operating preferences. Identify which sources share processing, which presenters use custom layouts, and which settings are fixed by station policy. This information helps the design team reproduce familiar behavior without carrying unnecessary legacy complexity into the new installation.
Map the new audio and control architecture
Ruby projects commonly place audio processing and routing in Power Core, with control supplied through Ruby surfaces and software tools such as VisTool. The exact design depends on the number of studios, required I/O, network topology, and operational model. A small studio may need a straightforward local configuration, while a broadcast center may require shared resources and resilient paths.
Define the network before the equipment arrives. Separate or logically organize audio, control, management, and synchronization traffic according to the chosen architecture. Confirm clocking, multicast behavior, switch capacity, link redundancy, and monitoring of critical network services. A network diagram should show normal and failure paths, not just the preferred route.
The European broadcaster case study illustrates why large organizations benefit from considering standardization, scalability, and operational consistency together. Those same principles apply to a smaller facility, even when the implementation is more compact.
Compare the operator experience
A migration is successful when presenters can work confidently during a live program. Ruby should be configured with a deliberate surface layout rather than a generic factory arrangement. Place the most frequently used sources where operators expect them, preserve useful visual groupings, and make essential functions visible without relying on hidden menus.
| Area | Existing Zirkon workflow | Ruby migration focus |
|---|---|---|
| Mixing | Physical faders and console-based control | Recreate familiar layouts while allowing configurable surfaces |
| Processing | Existing console or system DSP structure | Define processing ownership and presets in the new architecture |
| Routing | Fixed or semi-fixed source paths | Build documented, flexible routes through the network |
| Talkback and mix-minus | Dedicated studio logic | Reproduce every contributor and return-feed scenario |
| Monitoring | Console-selected monitor sources | Validate source selection, dim, cut, and alternate monitoring |
| Expansion | Hardware and frame capacity | Plan software, I/O, and network growth from the beginning |
Run usability tests with experienced Zirkon operators before the cutover. Ask them to perform a complete program sequence: prepare a guest, take a microphone live, play a clip, create a telephone mix-minus, monitor an off-air feed, and recover from a failed source. Their feedback often identifies small layout or labeling changes that prevent major live-operation errors.
Treat presets and automation as project assets
Presets should be reviewed rather than copied without analysis. Some Zirkon settings may reflect historic workarounds, unused sources, or outdated production habits. Ruby offers an opportunity to simplify these arrangements, but changes should be made visibly and documented so that operators understand what has moved.
Define naming conventions for sources, buses, destinations, users, and snapshots. Consistent names become increasingly important when one control position can access multiple studios or when engineers troubleshoot remotely. Establish who can edit system-wide resources and who can change local show settings.
If the station uses automated playout, news workflows, or external control, test those interfaces early. Confirm trigger behavior, tally states, serial or GPIO requirements, and the timing of transitions. A console can sound correct while an automation dependency remains incorrectly mapped.
Build a staged commissioning plan
Avoid making the first live transmission the first full-system test. Commission the Ruby environment in stages: verify network and synchronization, test I/O, validate routing, configure surface behavior, check processing, and then rehearse complete programs. Keep the Zirkon system available as a fallback until the new workflow has passed agreed acceptance tests.
Parallel operation can reduce risk, especially for newsrooms and stations with multiple studios. Migrate one room or one operating mode first, record the results, and apply the lessons to later rooms. Where parallel operation is not practical, schedule a controlled cutover with clear rollback criteria and technical staff on site.
Training should cover routine operation and failure recovery. Operators need to know how to identify a missing source, switch to an alternative monitor feed, manage a failed control connection, and report a network or processing issue accurately. Engineers should receive deeper training in configuration, permissions, backups, and software lifecycle management.
Keep the migration focused and measurable
Use a short set of acceptance criteria that reflects daily broadcasting rather than equipment features:
- Every critical source, destination, and mix-minus path has a documented normal and backup route.
- Operators can complete core live tasks without relying on undocumented workarounds.
- Monitoring, talkback, tally, and automation interfaces behave correctly in rehearsal.
- Presets, permissions, configuration backups, and recovery procedures are stored and tested.
- The station has a defined support process for the first weeks after cutover.
Ruby can provide a strong foundation for a more adaptable broadcast operation, but its benefits appear when the design connects technology with working practices. Treat the project as a workflow migration, validate it with the people who operate the studio, and use staged testing to protect the audience from avoidable disruption. Begin with the Zirkon inventory, define the target architecture, and turn the approved design into a practical commissioning schedule.
