Reach Schedule: speed up / slow down timers

[cpvalente]

This has been part of the roadmap from the beginning and I believe we are ready to implement. We need a way to control the speed of a timer.

Currently we are able to add and remove time from a timer, but speed controls tend to be invisible to the speakers and slightly more friendly

I suggest this could be an extension of the Playback Control and contain the following feature set:

set speed input / slider

• we would input a speed value in % (eg: 110&) and be able to see an expected finish time before submitting the change, the expected finish field should consider the speed override meet End Time
• it would be important to tell ontime to calculate a speed that meets an event's deadline, this would populate the field described above and the user can choose to submit the change

few questions:

• should ontime limit speeds or leave it up the user?
• how about APIs? what would an HTTP / OSC / Websocket API look like? set-timer-speed 110 ?

[cpvalente]

With the discussions we had with users, this seems like the wrong direction for the app and we are inclined to cancelling this.

It seems that we do a better job at focusing on time keeping and event sequencing. The manipulation of time could be detrimental to being able to accurately keep track of our event sequence

leaving this open for a while longer to give users a chance to share thoughts

[tcconway]

When I used to use an app called "productionTimer", I'd use this functionality all the time. It's called "Time Travel". When in Time Travel mode, the interface changes color as to notify you are in this mode. Super super useful to make up time during a long-winded talker! Take a look at the app for inspiration!

[cpvalente]

This was something that we defined as part of the roadmap in the very first prototype of ontime. The feature description is to have a small slider that allows to adjust time, with a time input where we can "prototype" what speed the timer needs to run at to finish at that time.

We called this Meet Deadline:

• it is 10:05:00
• I need the current speaker to be finish at 10:10:00
• I would enter 10:10:00 and click Meet Deadline
• The speed slider would then show me that I would need to adjust the speed to x1.25 to meet the given end time
• We click apply and rejoice

However, my current thoughts go along the lines of, is it in the scope of a time-keeping application to manipulate the fabric of time?

• this feature conflicts with the plans of ontime receiving and sending timecode. In the cases where we receive timecode, this would not be possible. In the cases where we send timecode, this would not be desirable.
• would it be best (even if not as convenient) to expect directors/operators to manipulate event scheduling explicitly?

We would also need to consider that any time developing this feature is not used in developing something else. Potentially more aligned with the app usage

Altogether, my current feeling is that there are too many downsides.

But I am willing to be convinced, even if by the argument: "Ontime users really want this".

[tcconway]

Great points.

I think there's a world where there are both scenarios:

• Timecode driven
• User alter driven

Each would lock each other out, to make things simpler. What I mean is if you are using Timecode, you couldn't timeshift. If you are timeshifting, you couldn't enable timecode etc etc.

To me, I'd use both features, albeit not on the same show. There's a definite need for timeshifting and for Timecode on different shows...and I've never run across where I need both at the same time. Both use cases fall into the scope of a time-keeping application.

As for a timekeeper operator having this type of timeshifting control...YES. For every corporate event I run, I am asked by the show producers to adjust time for every one of them. Having a timeshift feature basically keeps it so we keep the show on time, but doesn't put us in the awkward position of throwing off the presenter while they speak.

I think this is a gamechanger.

[dillwishlist]

I would like to add my enthusiastic support for this feature. I work in live event production in both academic and corporate settings, and having the ability to meet a deadline for lunch, catching transportation, class change, or even simply the next speaker can not be overstated. This is a feature of some professional level speaker timers and would bring this amazing project even more useful applications.

A big, colorful warning could be shown on screens (default, but optionally for each) to make sure everyone that is supposed to knows what's going on. I searched the issues before adding my own feature request and came across this thread. Please, add support for this mode.

Thank you in advance!

[acdolph]

I 100% agree with the comments above - in the event production world where I live, we need to manipulate time all the time. I do think it’s important to be unmistakably clear in the control interface that we are messing with time, but having it totally invisible that it’s happening on the stage and audience displays is also critical.