RFC: Blueprints defined timers "T-timers"

[jesperstarkar]

About Me

This RFC is posted on behalf of BBC, as one of 3 RFSs focusing on timing in Sofie.

Use Case

Example use cases:

1. Countdown to break. There can be multiple breaks we need to hit during a show. We need to orchestrate which ones are being counted towards when, in relation to time and show progression.
2. Count to "stop talking". Count to a specific duration in the show that marks a specific milestone which is important to hit precisely.
3. The concept is generic, and Blueprints defined, meaning many timing concepts in Sofie can be represented through this system.

We need:

• Free-running countdown timers that can be started and run unaffected by the progression of the show.
• The ability to diff such a free-running countdown towards a specific Part ahead of us in the rundown, to display over/under calculations.
• APIs to define and control such timers from the Blueprints, both during ingest as well as during the show execution.
• UI displays of these T-timers in the Top Bar, on the Presenter's screen, on the Director's screen, on the Prompter.
• LSG data on configuration and state of the T-timers.

Proposal: T-timers

This is an addition to Core (Playlist data model, Core backend, UIs, APIs).

We will introduce a new concept called "T-timers". There will be a fixed set of 3 such timers, T1, T2 and T3. By making it a fixed and named set, it becomes a concrete feature both users and developers can point at and refer to.

T-timers can be configured to become active. They have the nature of counting down, either a fixed duration or towards time of day. Duration-based countdown can be paused and resumed.

The T-timers will be configured to instruct their UI or LSG representation on how they should behave towards the user: Freeze at 0, Continue counting up/past 0. Counting down a duration of 0, allowing it to count up effectively means counting up (stopwatch).

T-timers can be configured during Blueprints ingest operations. They are also exposed in the context available for hooks such as onSetAsNext and onTake, as well as to the Adlib Actions.

They will be configurable over the HTTP API for control, as well as over the LSG for consumption in 3rd party applications.

UI implementations will have CSS classes reflect the state of the component, so that custom CSS overrides enable styling and visual behaviour.

Reasoning for doing this

It is evident that timing calculation is bound to editorial and production workflows, hence they need to be defined and owned where shows design and logic is implemented: in the blueprints.

Exposing blueprints API to express and control timing is missing in Sofie. This means that all previous timing needs have ended up as native Core implementations. That does not scale with the number of unique Sofie use cases. We believe some of the later additions of specific/narrow timing concepts in Core would not have been natively implemented had this Blueprints API existed earlier, which gives us confidence that this is an improvement for the better. We want to make timing easier to work with for ourselves, as well as across Sofie projects in open source space.

Process

The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.

• RFC created
• Sofie Team has evaluated the RFC
• A workshop has been planned
• RFC has been discussed in a workshop
• A conclusion has been reached, see comments in thread

[jstarpl]

I've got a question for me to better understand the proposal: is the need for The ability to diff such a free-running countdown towards a specific Part ahead of us in the rundown, to display over/under calculations. covered by the T-Timers as proposed, or is this a generic need, but not yet fulfilled by the proposal? I'm asking, because the proposal says that the T-Timers have two modes: duration-based and wall-clock-based, but to me it seems that the countdown towards a specific Part would have to be a third mode? Or am I missing something?

Also: How do you think these T-Timers would be "scoped"? Would they exist on a per-Segment? per-Rundown? per-Playlist basis?

[jesperstarkar]

1. The over-under-diffing will be included as a feature on T-timers, but will not be implemented as countdown towards a specific Part. That mode is a natural extension of the T-timers feature set, which has been imagined and considered in our design work. The ongoing scope of work from BBC does not include the countdown towards a specific Part mode. However, it will allow any countdown (duration based or towards time of day) to Diff against a specific Part.

It is only natural to think such third mode will be added later for the sake of feature completion, where the difference is that your target Duration will be read from the amount of content from Live to Part X, instead of explicitly set.

2. We are planning to place the T-timers on the Playlist model