Triggering Station Clocks with RƎLAY Virtual MIDI
RƎLAY Virtual MIDI creates a software route for sending control events to studio clocks, countdown displays, jingle players and timer panels. Its value lies in deterministic triggering: when a show, advertising break or live item starts, a defined MIDI message tells the receiving device what to display or do.
That makes it well suited to Australian radio, where breakfast presenters in Sydney or Melbourne may need an on-air countdown while a reporter joins a Brisbane studio or a regional network takes over. The operational clock must remain legible in 24-hour local time even when automation is scheduled against UTC.
RƎLAY cannot make incompatible hardware understand one another, however. A MIDI-capable clock, a timer driven by relay contacts and a display controlled over IP require different arrangements. The receiver therefore needs to be documented before any message is assigned.
MIDI Clock, the transport-tempo message at the heart of MIDI timing, should not be confused with a station’s wall clock. A reliable setup uses RƎLAY playout events as the trigger source, maps them deliberately and gives the clock a sensible state when messages stop.
Choose a compatible control method
Start with the receiving device: its model, firmware, MIDI input, supported messages and behaviour after a restart or network interruption. Check whether the RƎLAY host can see the intended virtual MIDI endpoint. A physical clock connected through USB or DIN may also require a local interface, while a networked clock may need a gateway.
| Control method | Typical use | Advantage | Configuration concern |
|---|---|---|---|
| MIDI Note On/Off | Start or stop a countdown and show running state | Simple and widely understood | Match note, channel, velocity and reset behaviour |
| MIDI Control Change | Toggle a status display, reset a timer or change pages | Supports several discrete states | Define the value assigned to each state |
| Program Change | Recall a named timer or display preset | Compact control of prepared scenes | Keep program numbers documented |
| Relay or network command | Operate equipment without native MIDI support | Broad hardware compatibility | Requires suitable interface hardware |
For most studio timers, a Note On starts a preset and a Note Off stops it. Control Change is useful when the display has several modes, while Program Change suits clocks with stored scenes. These are common patterns rather than universal RƎLAY presets, so the clock’s documentation remains authoritative.
Map RƎLAY events to MIDI actions
Define each source event before configuring its message. Typical events include the start of a live segment, the beginning and end of an advertising break, a manual news cue and the handover to a networked studio. Giving every event a meaningful name makes troubleshooting much faster than identifying it later as an unexplained Note On.
In the RƎLAY Virtual MIDI configuration, assign the source event to a MIDI action and select its destination endpoint. Specify the channel, message type, data values and timing. If several clocks display the same information, use matching mappings rather than sending different messages to each device.
A MIDI note normally starts or stops an already configured duration; it does not automatically carry the exact remaining time of a media file. When that precision matters, configure the clock’s preset in advance or use a receiver capable of accepting time-position data. Log the event identifiers as well as the MIDI output so duplicate or missing triggers can be traced.
Match the receiving clock
The RƎLAY output and clock input must use identical values. A Note On on channel 1, note 60 and velocity 127 will not trigger a clock configured for Note On on channel 5, note 60 and velocity 100. Also decide whether the clock should stop, hold its last value or clear when it receives the paired stop message.
Check startup behaviour as well. A practical clock should show a known time and an unambiguous off-air state after a power cycle, rather than implying that a broadcast is still active. Test this on the actual display used in the studio, since operating buttons and menu settings may affect the MIDI input.
Where the route passes through Lawo nodes and another vendor’s controller, third-party node control explains the relevant Lawo-side control architecture. This helps separate playout-event mapping from the network path that carries those instructions.
Handle Australian time and compliance
Keep the automation timeline in UTC and apply the required civil time zone only when information reaches an operator or display. Broadcasters commonly use 24-hour time, but network programmes may follow AEST even when a Brisbane or Perth presenter sees local time. The chosen policy should be documented and visible in the studio.
Daylight saving adds another layer. New South Wales, Victoria, South Australia, Tasmania and the Australian Capital Territory move between AEST and AEDT, while Queensland, Western Australia and the Northern Territory do not. Lord Howe Island also uses a half-hour offset. A station displaying both local and network time should calculate each zone independently.
ACMA licence conditions and a station’s approved engineering arrangements remain the responsibility of the licensee, although they do not prescribe MIDI mappings. Commercial networks, ABC services, community broadcasters and regional operators should include clock behaviour, time sources and fallback displays in their operating procedures. Accurate timing supports advertising, news bulletins, traffic reports and audience expectations without treating the display as the broadcaster’s sole time reference.
Protect against failures and remote sites
Define the clock’s safe state before launch. If RƎLAY stops sending messages, the display should either continue from its last confirmed value with an appropriate visual warning or return to the approved standby screen. Silent freezes can leave presenters believing a break is still running.
Keep control traffic on a stable studio network where possible, separate from general office traffic. Remote contributors may justify a gateway or dedicated route, but latency and link failures must then be included in testing. Monitoring should report both the RƎLAY event and the resulting clock state, while a spare configuration or local fallback protects essential countdowns.
Test the chain off air
Begin with direct MIDI tests so each message can be isolated from the playout system. Confirm the clock’s visible response, especially for overlapping events, reset commands and rapid start-stop sequences. Then test the full path from the RƎLAY event through the virtual endpoint and any interface hardware.
Power-cycle the clock and host, interrupt the network and restart the RƎLAY service. Each test should confirm that no stale “on air” indication remains and that the next scheduled event behaves correctly. Test daylight-saving boundaries, overnight programmes and manually inserted items rather than relying only on the normal automated schedule.
A final rehearsal should follow a familiar Australian breakfast or drive-time sequence, including news, commercials and a live remote item. This exposes timing assumptions that isolated tests may miss, particularly when operators must interpret a countdown while handling another task.
The timing chain to remember
The dependable chain is straightforward: a named RƎLAY event produces a documented MIDI action, the receiver interprets that action consistently and monitoring confirms the result. UTC scheduling, Australian time-zone handling and explicit failure states complete the arrangement.
A station clock becomes trustworthy when every trigger is mapped, observable and recoverable, with the display confirming the same state as the playout system.
