RFC: Allow modification of global AdLibs during a rundown / Modify display properties of upcoming pieces #1678
Description
About Me
This RFC is posted on behalf of the BBC.
Use Case
We have some Global Adlibs/Actions for driving camera robotics. The exact behaviour of those adlibs vary depending which portion of the rundown is currently playing.
We would like the naming of those adlibs to reflect their current behaviour instead of some generic wording.
Additionally, we need to be able to update some display properties of upcoming pieces often beyond the next PartInstance. This includes: display name, source layer and potentially things like hover previews.
This is largely to cause a different visual look through the different portions of the show, which also affects other things like graphics. The content side of this we can achieve today through adlib actions and the onSetAsNext and onTake callbacks as well as infinite pieces to update the ‘baseline’.
Proposal
We believe this is a workflow in Sofie that is not uncommon, and is not well catered to today. Some of this we can workaround with infinites and performing various mutations during onTake and onSetAsNext.
Sofie does have a similar concept, which is to use multiple Rundowns in a RundownPlaylist, and use a different ShowStyleVariant for each Rundown. That is an approximation of what we would like to happen, but with greater ability to jump around the content without the variant changing, and within the limitation that this is one Rundown in the NRCS.
We believe some other Sofie users have encountered similar issues, and have also resorted to using infinites to affect the output in different ways as the show progresses.
To accommodate this, we propose adding an ability for the ShowStyleVariant to change throughout a Rundown, and for the content to be generated for multiple variants.
The Rundown
On the Rundown, this could be reflected by treating the current ‘showStyleVariant’ as the default variant. The rundown should declare which variants it supports changing to.
The rundown baseline and global adlibs/actions would be generated for the default variant, and gain a new property to describe any property overrides that should be applied for different variants. Sofie would then be responsible for considering merging the correct overrides onto the object at the appropriate points.
Using an adlib-piece as an example:
export interface IBlueprintAdLibPiece {
// Some properties that already exist today
name: string
// more would be here
// describe partials to overlay for each override
variantOverrides: Record<string, Partial<IBlueprintAdlibPiece>>
}(This is a rough sketch of how this could look. The types will need structuring better for this, and some thought may need to go into being able to unset properties, and perhaps to disable/hide the adlib altogether)
Q) should variantOverrides be an object keyed by variantId, or maybe it should be an array of ‘layers’ with each layer having an variantIds defining which variants it applies for. The array approach would allow for a more granular layering approach and hopefully reduce duplication (thinking here of when multiple variants want the same behaviour)
I am not 100% sure how many of the properties of each document should be possible to affect with the variants, this will want some thought. This may want to be kept as minimal as possible initially, which will help to reduce the impact of this change. Currently we only need this to affect the UI properties, but it could simplify other logic if the playout properties could be affected too.
The parts/pieces
Similarly, the parts and pieces will want a similar variantOverrides approach. This will not propagate into PartInstances/PieceInstances, they exist as playout documents and by the time they are created we know what variant they will be for, so will be in the flattened forms.
During playout
It should be possible for adlib-actions as well as some of the blueprint playout methods to change the active variant amongst the ones the rundown declares as being supported.
Q) I suspect the best place to track the activeVariant is inside the SelectedPartInstance objects on the RundownPlaylist. That will allow for tracking how it progresses as the PartInstances are taken. (Or perhaps on the PartInstance themselves? perhaps both?) This will be important so that lookahead can be aware when the next partinstance is a different variant to the current.
To avoid complexity for infinites, as this stage they should behave like pieces and become one variant. In the future this may want to change, but this can likely be worked around by replacing the infinites in the blueprints at the point of changing the active variant
Impact to the codebase
This will be a quite sprawling change to apply everywhere, but for users of sofie it doesnt require any changes to workflow or blueprint. Unless a rundown opts into allowing different active variants, it wont be possible to change the active variant.
The playout logic will need to handle simplifying the parts/pieces when creating the instances, when executing adlibs/actions, and when putting the baseline on the timeline.
Lookahead will need to be made aware, so that it can ignore certain pieces which are only relevant for certain instances.
The UI will need to be aware of this when displaying non-instance parts and pieces, as well as adlibs and actions in the shelf, dashboards etc.
Any blueprint provided syncIngestChanges logic may need to handle the overrides themselves, to ensure the correct version gets synced. We should provide some util for applying the overrides to make this easier
Alternatives
Alternatively, we could solve this by dispatching user-edits from adlib-actions, but due to the scope of this that will likely result in trigger a re-ingest of the whole rundown at multiple points during playout. Depending on the length of the rundown, this could have a notable performance impact.
We have a PR for this partly as a short-term solution for this: #1671
Future thoughts
Bucket adlibs are doing something already for generating different versions for different variants. This has been problematic in the past due to creating so many documents.
If this RFC goes ahead, it would be good to revisit the buckets structure to perform a similar layering approach for consistency.
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