Offline Ruby Show File Editing With VisTool
Radio teams often need to refine a studio configuration when the Ruby console is busy, installed at another site, or temporarily unavailable. VisTool provides a practical way to prepare interface changes, review pages, and organise control elements away from the live system.
This approach is especially useful for Australian broadcasters operating across several locations. A network may have a main studio in Sydney, a regional production room in Toowoomba, and a backup facility in Perth, with engineers supporting all three. Working offline reduces travel, interruptions, and pressure on an on-air console.
The key is to understand what can be changed safely in the VisTool project and what still requires validation against Ruby, Power Core, or the wider Lawo system. A disconnected workstation can display and edit configuration data, but it cannot prove that a physical fader, GPIO signal, DSP path, or network destination behaves correctly.
The workflow below treats an offline copy as a controlled engineering workspace. It combines version discipline, visual inspection, simulation, and a cautious handover so that the final deployment is predictable when the console becomes available.
Why Offline Editing Matters
VisTool is valuable when producers or engineers need to adjust a Ruby user interface without taking a studio out of service. Pages, buttons, labels, metering layouts, navigation, and control assignments can often be reviewed on a separate computer before anyone touches the operational system.
That separation suits Australian radio, where breakfast programs, drive shows, and footy coverage can leave very little quiet time for maintenance. Community stations and regional broadcasters may also rely on a small technical team, making after-hours preparation a practical way to keep changes moving.
The wider Lawo broadcast platform supports networked and software-based workflows, so an offline VisTool task can form part of a larger preparation process. It should still be treated as preparation rather than a complete system test.
What To Gather First
Start with the most recent approved VisTool project and the matching Ruby show or configuration files. Include associated graphics, icons, fonts, templates, documentation, and any notes describing the current Power Core or routing environment. A missing asset can make an offline page look correct while behaving differently after deployment.
Create a working copy and preserve the original in read-only storage. Use a clear filename such as Station_Ruby_Main_2025-03-08_Working, then record who supplied it, which studio it belongs to, and the software versions involved. This is particularly important when a head office and a regional site exchange files over a managed link or ordinary file transfer.
Opening The Project Without Hardware
Launch VisTool on the editing workstation and open the project through its normal file workflow. If the software presents a target, connection, or runtime choice, select the local editing or offline mode rather than attempting to discover a console. The exact wording can vary between VisTool releases and installed components.
Once the project opens, allow it to finish loading before making changes. Check the page tree, navigation buttons, object properties, and visible assets. If warnings identify missing fonts, unavailable images, unresolved links, or unsupported elements, record them immediately instead of silently working around them.
A disconnected project may show the intended control surface without access to live values. Meter movement, source status, tally feedback, GPIO states, and hardware-specific responses should therefore be marked as unverified. This distinction prevents an attractive screen mock-up from being mistaken for a tested console configuration.
Editing Pages And Control Logic
For a straightforward change, work on one page or function at a time. Typical tasks include renaming a source, adjusting a button caption, reorganising navigation, resizing a control, changing colours, or adding a page for a recurring production format. Keep labels consistent with the station’s operating language; Australian teams may use “outside broadcast”, “OB”, and “remote” differently across departments.
Inspect each object’s assigned action, destination, scope, and feedback behaviour before editing it. A button that appears to select a microphone may also trigger a tally, change a mix-minus path, or recall a related control state. If the hardware mapping is unclear, change the visual layer only and document the required engineering check.
Save incremental versions rather than repeatedly overwriting one file. After each meaningful group of edits, close and reopen the project to check that the change persists. This simple test can expose broken references, missing resources, or a save made to the wrong project directory.
Checking Behaviour Offline
Use VisTool’s preview, test, or simulation functions where available. Click through every navigation path, verify that buttons have clear active and inactive states, and check that text remains readable at the intended display resolution. Test long station names, alternate source labels, and error or inactive conditions if the project supports them.
Offline testing is strongest for interface behaviour and weakest for system integration. It can reveal overlapping objects, poor page flow, incorrect labels, and confusing feedback design, but it cannot confirm an IP route, DSP subscription, console permission, or physical control response. Keep a separate verification list for those items.
The workstation display should also reflect the real studio environment. A darkened control room, bright daylight in a Perth studio, or a screen positioned near presenter lighting can affect readability. Basic studio lighting guidance can help when judging contrast and glare before the design reaches the console.
Preparing A Safe Handover
When editing is complete, save a release candidate with a new version identifier and export or package the project using the method required by the local Lawo installation. Do not assume that copying a single file is enough; linked assets and compatible project resources may be needed as well.
Include a short change record with the affected pages, renamed sources, altered actions, unresolved warnings, and tests performed offline. Note the target Ruby surface, VisTool version, Power Core relationship, and any expected network dependencies. This gives the engineer on site a usable checklist rather than a file with unexplained differences.
Before deployment, compare the candidate against the last known-good version. A file comparison may not expose every semantic change, so visual inspection and a written summary remain important. Keep the previous release available for rollback, especially before a major live broadcast or outside broadcast.
Offline And Connected Work Compared
The two modes serve different purposes. Offline work is ideal for preparation and design review, while a connected session is required for live-state confirmation and final integration checks.
| Activity | Offline VisTool workstation | Connected Ruby environment |
|---|---|---|
| Edit page layout and labels | Suitable | Suitable |
| Review navigation and visual states | Suitable with preview | Suitable |
| Confirm live meters and tally | Not available | Available |
| Verify DSP, routing, and permissions | Not available | Available |
| Test physical controls and GPIO | Not available | Available |
| Prepare a documented release candidate | Suitable | Suitable |
| Roll back to a known-good version | File-based | System-dependent |
A Repeatable Studio Routine
A useful routine is to copy the approved project, open it without hardware, inspect warnings, make one controlled change, preview the affected workflow, and save a clearly named release candidate. Then another person reviews the pages and change notes before the file is taken to the studio.
For a Sydney network, that second check might happen before the morning shift; for a regional station, it may be scheduled around a limited engineering visit. Either way, the final connected session should begin with a backup, a maintenance window, and a short acceptance test covering routing, feedback, and the controls that matter most.
Create the working copy, open it in VisTool’s offline mode, and record the first project warning before making any edits.
