Workflows for separate timers

[RasterboxOff]

Hello folks.

I’m just opening a thread to talk about probable use cases for separate timers in Ontime, since it is on the roadmap for v3. I‘ll be looking through the eyes of corporate events, which is most definitely not the only angle to look at that topic, so please chime in. :) I tried to summarize my thoughts as a t.l.d.r at the bottom.

Additional Timers within Ontime

As a starting point Ontime could mimic the options from Dsan Limitimer. This rather old school clock can set a session time and has three additional presets for other durations. This then can be used to keep track of the overall time to the next point in the schedule. That would be the session time and in Ontime that reflects the timer as it is right now – a countdown to the next Cue/Session/Scene.
Back to the Dsan example: If one of the other non-session timers is running, it overwrites the session timer. A use case might be a session where many people present their findings from group workshops and get 5 min each to present their conclusion. Separating that into many small cues in Ontime would be cumbersome and messy. Instead, an additional timer could be used for the short presentations while the original timer keeps running in the background and track of the overall schedule.

I don’t think Ontime would need several presets for timers within one cue, but rather the separate timer needs controls that make it easy and quick to program and change values (I think a companion integration would be very good, too). There’s a some real estate in the edit view on the left side below the current timer that could be home to the additional timer(s) maybe?

For this timer we would have to ask the question on how and if it interacts with the session/original timer. I think an overwrite option should be selectable in the timer views … or in the cues … or timers themselves? Meaning that when the separate timer is running, it overwrites the session timer and it switches back when either the separate timer ends, or when the operator chooses to switch back, or maybe the timer could freeze at zero for a certain amount of time before switching back automatically.
There are probably many ways on how that could or should work, all with ups and downs.
The separate timer should/could also be selectable as a source in the timer views.

External Timers

Another timer that seems to be on its way into v3 is the external source. I’m thinking of playback software like Mitti or QLab sending the remaining time of a running clip to Ontime and I’d suggest that this external timer should also be capable of overwriting all the other timers.

Displaying these Timers

I guess every view in Ontime has a different challenge when it comes to showing these extra timers. I guess many views need them, some only need the currently running timer, some might need them all at once.
How this could be managed easily and self explanatory might become a little tricky. Maybe labels that can be displayed with the currently running timer could be an option for clarity.
E.g.:
When the traditional Timer is running:
Time to next session: (<<<this would be the label text)
HH:MM:SS

When the separate timer is running:
Presentation time: (<<<this would be the label text)
HH:MM:SS

When the external timer is running:
Clip ends in: (<<<this would be the label text)
HH:MM:SS

Summary t.l.d.r.

Separate timers controlled by Ontime

• Additional timers that can be controlled within Ontime should be selectable as a source in views and also capable of overwriting the „normal timer“ when needed
• Each cue should have the option to set an individual starting time for that extra timer
• The extra timer needs quick access to change the starting, or currently running time – it should get full control via Companion, too. E.g. set time to XX:YY, up x minutes, down x minutes …
• Depending on the view it could be a permanent thing on the screen and be given a name for that

Timers from external sources

• Showing timers that come from other sources like QLab & Co.
• Ability to overwrite other timers when the external source is sending data

Showing these Timers

• Different views might have different needs how to display these timers
• Overwrite functions seems like a plausible feature
• Labels for different timers?

Separate timers not only give more options to control the run down, they also make paid stand alone software that is currently in use for speaker timers obsolete.

Please know that I am only spitballing ideas here and even though I word it like „it should do this and has to have that…“ I don’t intend to demand anything. I just like to provide a starting point for further discussion about these awesome planned features.

Cheers
Al

[cpvalente]

Hi @RasterboxOff,

Thank you very much for this detailed explanation. I apologise for the lack of official response

We have been working on the features related to this, which ended as Auxiliar timer and External message

Auxiliar timer

• a timer separate from the rundown, which the user can leverage to keep track of parallel tasks
• this timer can be shown in the views or shared to other software over the API

External message

• this is a generic placeholder for text coming from other software. This could well be text which describes a time string ie: 00:10:12. The major distinction is that we do not attempt to parse or understand it
• this is also available in the views and over the API

With the two separate datasets we hope to serve well the use cases that you identified and provide a good foundation for moving forwards.
I would be interested in hearing from you how well do the features serve your use case and whether we can identify next steps to strengthen these.

Thank you again