ontime
ontime copied to clipboard
cpvalente
Delay support in roll mode
Currently roll mode ignores delays.
This is because supporting it means editing the times as they run. ie: during a running event, we add a delay before of 10 min, this would mean the event started 10 minutes later and change the timer accordingly. I am unsure if that is the expected behaviour
With this in place we have a good opportunity to compare the realtime clock to the running event clock and provide feedback. Eg. we could add information on how delayed / ahead the overall planning is in some of the screens
I was thinking about this today. If the delays could have a "wait to continue" option when operating in roll mode, the next event would not start until a manual (OSC or button) trigger resumes the roll. The delay would be updated to the time it has waited, and then applied.
Thank you for this.
I believe it is important considering whether this should be a new playback mode. It could become confusing to the current use of roll, which is meant for unattended setups.
I am developing a redesign of the playback mode to allow the sequencing of events in a auto playback feature. Perhaps I should look into integrating something as you suggest, an auto delay which absorbs extra time between events?
@dillwishlist Could you provide a use case for the feature?
Hi As a framework of thinking through this - it’s very similar to managing cues in a cue list on a lighting console.
There are some variations but the idea here is each individual cue has its own trigger type and delay value. Go. Wait. Follow. Here a lighting console app that has the basics and is a good simple and easy to use https://support.obsidiancontrol.com/Content/Cues_and_Cuelists/Cue_Timing/Setting_Cue_Triggers.htm
Cheers a
Get Outlook for iOShttps://aka.ms/o0ukef
From: Carlos Valente @.> Sent: Sunday, March 20, 2022 12:23:20 AM To: cpvalente/ontime @.> Cc: Subscribed @.***> Subject: Re: [cpvalente/ontime] Delay support in roll mode (Issue #99)
Thank you for this.
I believe it is important considering whether this should be a new playback mode. It could become confusing to the current use of roll, which is meant for unattended setups.
I am developing a redesign of the playback mode to allow the sequencing of events in a auto playback feature. Perhaps I should look into integrating something as you suggest, an auto delay which absorbs extra time between events?
@dillwishlisthttps://github.com/dillwishlist Could you provide a use case for the feature?
— Reply to this email directly, view it on GitHubhttps://github.com/cpvalente/ontime/issues/99#issuecomment-1073038534, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHBF4PFFG5GWYWKAEUQ4GQ3VAX5PRANCNFSM5NDKNRRA. You are receiving this because you are subscribed to this thread.Message ID: @.***>
I guess it depends if you are using ontime as a timer manager or event rundown. In the event rundown scenario, delays concern the global event, rather than single instances.
Your explanation is very much inline from what I understand of the proposed "wait to continue". I believe the option to absorb overtime should be part of a fully featured delay event but it is really a matter of achieving a good design here. Could this tie in with #100 somehow?
Yes, perhaps the best approach maybe to combine 100 and 99, - perhaps an option tie an event and its following delay, so that the delay value is automatically calculated based on the event's running time. If an event is shortened, then the delay as a negative value and following event times are re calculated. If an event is late then the delay is positive and recalculation is also performed. These values are tracked but not 'realised" in the following delay until the event (which is forcing the calculation) ends. For example Event 1. 30 Mins Auto delay Event 1. (Calculated = -30) (Actual =0) Event 1 plays and the speaker speaks for 20 minutes. The Delay Calculated =-10, and the Actual delay time in only "copied" from the calculated value once event 1 stops and the next step in the flow is the delay.
Thinking through a workflow, if the delay was odd number, say 12 minutes, as show caller i may want to edit the delay value to say 10 minutes so the external display times are kept neat.
thanks Jason
On 3/21/2022 1:57:19 AM, Carlos Valente @.> wrote: I guess it depends if you are using ontime as a timer manager or event rundown. In the event rundown scenario, delays concern the global event, rather than single instances. Your explanation is very much inline from what I understand of the proposed "wait to continue". I believe the option to absorb overtime should be part of a fully featured delay event but it is really a matter of achieving a good design here. Could this tie in with #100 [https://github.com/cpvalente/ontime/issues/100] somehow? — Reply to this email directly, view it on GitHub [https://github.com/cpvalente/ontime/issues/99#issuecomment-1073301458], or unsubscribe [https://github.com/notifications/unsubscribe-auth/AHBF4PBYEGPAYFKPMR3UIR3VA5RH7ANCNFSM5NDKNRRA]. You are receiving this because you commented.Message ID: @.>
My use case is when I'm running an event with both fixed and variable timing.
I like to start all my shows on time, an example below. In this case we normally start right at 7. In the case of a presenter running late, quorum not present (for board meetings), etc. So I would like the roll to continue with a "built in hold" (to use rocket launch terminology) by default, but have the option to extend the hold if need be. Maybe a "pause hold until manually released" OSC/switch toggle which is normally disabled could be useful.
4:00 pm - 6:00 pm Venue Setup 6:00 pm - 6:30 pm Tech Dinner 6:30 pm - 6:58 pm House Open 6:58 pm - 7:00 pm Hold for final checks with presenter/talent 7:00 pm - 9:30 pm Event
This could also be useful when interspersing events locked to timecode (a piece of music set to track, video roll, etc) with live scenes or transitions.
I would like to use onetime as a timer manager and an event rundown manager simultaneously. I would make the big event rundown parts public and every scene/cue/timer listed in the presenter/backstage displays. I can see how merging 100 and 99 would be the best way to do this, though it seems a lot bigger than what I initially envisioned.
Thanks, Alexander
Hey @dillwishlist, great stuff. It is good to clarify use cases. Would something like mentioned above work? This could be a good workflow for manually ran shows
perhaps an option tie an event and its following delay, so that the delay value is automatically calculated based on the event's running time.
Yes, I think it could work. The self-running roll mode is really great. I would suggest including a default wait time for the delay. If not overridden, it will automatically continue when that wait is complete. Then you can run it automatically unless you have to override it.