ontime
ontime copied to clipboard
Feature Request: 'On Custom Time'
Hello, Currently there are OSC and HTTP integration triggers for: On Load, On Start, On Pause, On Stop, On Every Second and On Finish.
I would like to see a 'On Custom Time' trigger added to this.
For example, triggering an event when the timer has 15 seconds remaining. Sometimes things have to be ready in preparation for the start of the next event. Triggering the end animation of a graphic, playing music that is timed to finish at the end of an event, changing lighting, changing monitor sources.
It would be nice to have 'On Custom Time From Start' but I believe that 'On Custom Time From End' would be most valuable.
Thank you!
Hi @staticlondon , thank you for reaching out and bringing this up.
I fear such logic could be abused by users and would like to see some proof of performance first. We have been conservative with the integrations for this exact reason
One alternative I have in mind is the current work on making warning and danger time set per timer. #624 ie: the user should be able, for each event, do define a time before end where these events are triggered.
It would then make sense that we would have an event onWarningTime
and onDangerTime
which you could use. What do you think?
Maybe warning and danger times should be called something else 😅
Hello @cpvalente, thanks for all your work on this software.
I think this would achieve the same results, so I would welcome that. I'm happy to test it out if you decide to introduce it.
We have a few things moving and will prioritise finishing ongoing work. This feature is pretty straightforward and I hope we can get it into the app early next year
Context
Currently all the timers are attached to the a lifecycle milestone such as something starting or finishing. We would like to be able to prepare integrations for an upcoming change
The task
We would want to create two new lifecycle triggers onWarningTime
and onDangerTime
, this should be available in the integrations and leverage the timer warningTime
and dangerTime
fields
This task depends on #624
I wonder if we could also find a better name for warningTime
and dangerTime
Warning and Danger might unintentionally limit what the feature is used for. I think 'Alert' for the first timer and 'Alarm' for the second timer has more flexibility.
Thank you @staticlondon , I completely agree that warn and danger are not ideal and we should revisit.
I think your suggestions is very solid, but it seems like they could be synonymous, ie: it is unclear which one comes first. In the case of Ontime, we would always need one of them to come first (which warn and danger achieves well)
In a theater setting this would be a warning
and a standby
, which I am unsure is relevant.
Maybe something simpler like warning1
and warning2
?
Maybe something else altogether?
I would appreciate some help here
Alarm1 and Alarm2, Alert1 and Alert2, CustomTime1 and CustomTime2, TimeFromEnd1, TimeFromEnd2, UserTimer1, UserTimer2, Notification1 and Notification2 would all work as they are a clear description of the functionality.
Will it matter what comes first from a user's perspective? If the first trigger is empty then does it impact the second trigger?
Alarm1 and Alarm2, Alert1 and Alert2, CustomTime1 and CustomTime2, TimeFromEnd1, TimeFromEnd2, UserTimer1, UserTimer2, Notification1 and Notification2 would all work as they are a clear description of the functionality.
Will it matter what comes first from a user's perspective? If the first trigger is empty then does it impact the second trigger?
It matters in the case of ontime since we use these fields to display the colours in the progress bar a user would typically use colours to signify the event nearing its end (orange and red) and regardless of the choices, it could be confusing to have the order swapped across events
alert and danger events are now available to the integrations feature. That will allow users to attach custom events to the timer progress.
As for free running events at user given times, we consider this to be out of scope. As a workaround you could pipe the output from ontime to a show controller
Closing this for now, please feel free to reopen if there are any other points for consideration