Timing is one of the most technically demanding aspects of live broadcasting. A show may need to fit exactly into a 27 minute window. A news bulletin might need to hit commercial breaks at precise times. A sports broadcast may have unpredictable durations that require constant rebalancing.
This is why modern rundown software includes a sophisticated timing engine capable of calculating and recalculating timings in real time. These timing engines are far more advanced than simple spreadsheet formulas. They must evaluate structure, sequencing, filler logic, over/under calculations, cascading changes, and on-air deviations as they happen.
A timing engine begins with the concept of planned duration. Each rundown item has a preset length. The engine sums these to determine whether the show fits its intended broadcast window. But planned duration is only one part of the equation.
Actual duration matters even more. When the show goes live, real time clocks track how long each story actually takes. The timing engine compares actual against planned and adjusts the overall outlook. This calculation must occur every second with zero drift.
In older NRCS systems, timing engines were local processes running on a server inside the newsroom. Modern cloud-based rundown systems must distribute timing logic across multiple servers and clients. This requires extremely accurate synchronization protocols like NTP, PTP, or WebRTC time alignment.
Falcon Rundown uses a distributed clock synchronization approach that ensures all clients share the same reference time. This enables directors and producers to see identical timing numbers regardless of location.
A timing engine must also support fills and floats. Some items shrink or expand automatically based on time remaining. This requires conditional logic in the rundown structure.
In addition, the timing engine must interpret control events such as:
- story started
- story completed
- story skipped
- story extended
- commercial break inserted
Each event adjusts timing for all subsequent items. This cascading calculation is the hardest part for spreadsheet-based systems to replicate. One miscalculation cascades into a show-wide error.
The timing engine must also support multiple timing modes:
- rehearsal
- air time
- hard time
- soft time
- back timing
Back timing is particularly complex. It ensures the final items align exactly to the show’s out time. This is essential for broadcasters that must hit precise satellite windows or commercial breaks.
Modern rundown systems like Falcon Rundown also integrate timing with cuecards, scripts, and automation layers. When timing shifts, cuecards adjust presenter expectations. Automation systems recalibrate transitions. Graphics engines adjust animation timing. Prompters may slow or accelerate scroll speed.
This interconnected timing architecture allows the entire control room to stay synchronized.
A strong timing engine also mitigates latency. Cloud systems must handle network delay gracefully. If a user’s connection lags, the system should interpolate timing locally until it reconnects and resyncs.
Finally, timing engines must be failure resistant. If one client disconnects, the show continues. If a server restarts, timing persists because the engine is distributed.
Timing is not just math. It is a real-time, multi-layered, synchronized, distributed calculation engine that must never fail.
Falcon Rundown’s timing logic demonstrates the importance of modern broadcast rundown software. It transforms timing from a manual burden into a reliable, automated foundation for live broadcasting.