René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"RFC: Blueprints defined timers \"T-timers\"","articleBody":"### About Me\n\nThis RFC is posted on behalf of BBC, as one of 3 RFSs focusing on timing in Sofie.\n\n### Use Case\n\n**Example use cases:**\n1. 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.\n2. Count to \"stop talking\". Count to a specific duration in the show that marks a specific milestone which is important to hit precisely.\n3. The concept is generic, and Blueprints defined, meaning many timing concepts in Sofie can be represented through this system.\n\n**We need:**\n- Free-running countdown timers that can be started and run unaffected by the progression of the show.\n- The ability to diff such a free-running countdown towards a specific Part ahead of us in the rundown, to display over/under calculations.\n- APIs to define and control such timers from the Blueprints, both during ingest as well as during the show execution.\n- UI displays of these T-timers in the Top Bar, on the Presenter's screen, on the Director's screen, on the Prompter.\n- LSG data on configuration and state of the T-timers.\n\n### Proposal: T-timers\nThis is an addition to Core (Playlist data model, Core backend, UIs, APIs).\n\nWe 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.\n\nT-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.\n\nThe 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). \n\nT-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.\n\nThey will be configurable over the HTTP API for control, as well as over the LSG for consumption in 3rd party applications.\n\nUI implementations will have CSS classes reflect the state of the component, so that custom CSS overrides enable styling and visual behaviour. \n\n### Reasoning for doing this\nIt 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.\n\nExposing 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. \n\n### Process\n\nThe Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.\n- [x] RFC created\n- [ ] Sofie Team has evaluated the RFC\n- [ ] A workshop has been planned\n- [ ] RFC has been discussed in a workshop\n- [ ] A conclusion has been reached, see comments in thread\n","author":{"url":"https://github.com/jesperstarkar","@type":"Person","name":"jesperstarkar"},"datePublished":"2026-01-19T09:57:19.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":6},"url":"https://github.com/1601/sofie-core/issues/1601"}