Feature Request: Support for Multiple Concurrent Timers (e.g. Plenary + Breakout Sessions)

[jeoooo]

Feature Request: Support for Multiple Concurrent Timers (e.g. Plenary + Breakout Sessions)

hi @cpvalente!

I'd like to request a feature (or get clarity on a workaround) for supporting multiple simultaneous timers. Here's the scenario:

In a single event, we often have a plenary session running alongside one or more breakout sessions. Each of these needs its own independent countdown or elapsed timer, as they run in parallel and are managed by different teams.

Currently, Ontime seems to be centered around a single master timer per cuesheet. While cues can be grouped and filtered, only one timer appears to be active globally.

Ideal Outcome:

• Ability to define two or more active timers running in parallel.
• Each timer could be tied to a specific cue group (e.g. plenary, breakout-1, breakout-2).
• These timers should update independently and be accessible via custom viewers or standard views filtered by group.

Workarounds I've Considered:

• Running Ontime instances on different machines (1 for plenary, 1 for breakout)

---

While these help, native support for concurrent timers would make it easier to manage complex event flows under a single Ontime instance.

Let me know if this is something feasible for a future release, or if there's a recommended best practice I might be missing. I'd be happy to help test or explore the feature further.

Thanks again!

[cpvalente]

Hi @jeoooo, thank you for taking the time to reach out and your detailed request.

We have had similar requests and spent a considerable amount of time thinking of these flows.

We have never found a solution that feels natural to Ontime. This function would be better suited for a timeline like application or something that has some sort of playhead that can be matched against many elements

The current way to do this in app is by leveraging the auxiliary timers.

As an extension, the new version has several primitives which can be useful here, including 3 aux timers, flags and group level timers. I expect that having different screens focusing on their timers is reasonable

As a first step we can confirm that the aux timers provide a viable workflow. What do you think?

[jeoooo]

We have never found a solution that feels natural to Ontime. This function would be better suited for a timeline like application or something that has some sort of playhead that can be matched against many elements

@cpvalente perhaps the approach to this might be something like we can group timers together, and then add a flag such that these flagged timers can be controlled separately?

As a first step we can confirm that the aux timers provide a viable workflow. What do you think?

this seems fair for now, tho will have to check them out in the next version tho :D

[cpvalente]

@jeoooo you can download the new version from the release page
https://github.com/cpvalente/ontime/releases

[jackcrombie]

Maybe there's a way we could use multiple instances of Ontime, and have an API connection, so one ontime is the parent instance and sends start item calls to the child instances for breakouts. it could be done with the automations feature, but with some added API integration that can get the list of timers from the child instances. it could be done with OSC currently but the API integration to get items would make it user friendly rather than raw osc commands which makes it a little user hostile.

I'm keen to explore the groups features too.

[cpvalente]

Hi @jackcrombie , thank you for this.

We are currently working on stabilising the new v4 release but concurrent rundowns is something we are actively investigating.

I it is still not clear to me how this could be done but we have bounced similar ideas of a view that shows data from many instances.
Would you be interested in joining our discord channel (link in the readme) I can make a group on this and schedule a chat to look at possibilities