RFC: Simplify Studio & ShowStyle relationship

[Julusian]

About Me

This RFC is posted on behalf of Superfly.

Use Case

We feel that Sofie has unnecessary complexity and confusion surrounding the handling of multiple studios.

The main aim of this is to solve the issue of there not being any shared config between the ShowStyle and Studio during the applyConfig blueprint methods. This makes it incredibly hard to generate sensible SourceLayers and LayerMappings without either making assumptions or requiring config to be defined in both places.

For example, each Studio Monitor needs at least one SourceLayer to put the pieces on, and it translates to some hardware resource (such a CasparCG channel or chef window), so needs mappings to be created too.
Ideally this could be driven by a blueprint config table in the Studio settings, with the ShowStyle blueprints able to use this config table too. This is not possible today.

Proposal

The challenge with the config, is that there is currently a M-N relationship between ShowStyles and Studios. Each Studio can use any number of ShowStyles, and each ShowStyle can be used in any number of Studios.

For this reason, the ability to access the Studio config was never given to the ShowStyles, as handling this correctly in blueprints will be complicated. The hope was that it could be simplified, then config would be exposed.

I see 3 possible approaches to making this possible:

1. Limit Sofie to only having one Studio
2. Limit ShowStyles to only be usable by one Studio
3. Provide an array of Studio configs to the ShowStyle blueprint

1) One Studio

As far as we are aware, no installation of Sofie has more than one Studio within the installation. So we want to question whether the current structure is correct, or if it should be simplified.

From what we have seen this is a combination of:

Wanting to roll out updates to a single Studio at a time

Isolation. Any studios that would make sense to group are often backups for each other. Sharing a Sofie installation adds risks that an issue in the shared installation would make both studios unusable.

So perhaps Sofie should enforce this and be limited to one studio?

As a developer of Sofie, I sometimes wonder how well Sofie will handle multiple studios. As no-one has really used it, are there areas of the code which are not checking the studio boundary correctly, and so could leak data/operations across? By introducing this limit, this would no longer be something to worry about.

Short term, this would be simple to limit the creation of additional studios and let developers make assumptions about there being one studio going forward.
Long term, various portions for handling multiple studios could be cleaned up.

2) One Studio for a ShowStyle

Another option is to limit it so that a ShowStyle is only being able to be used in one Studio.

This directly solves the blueprint config issue without trying to change Sofie much.

I expect this would be pretty simple to implement, simply replacing the supportedShowStyleIds property on the Studio document with a studioId property on the ShowStyle document.

3) Make it work as is

There is no reason it couldn’t work as is by providing an array of studio configs into the relevant blueprint config methods. However, this adds confusion and complexity for blueprints developers.

In most cases, it would likely be fine for blueprints to simply assume that considering just the first config in the array and it would be fine (based on installations we have seen having only one of each). But it will be easy to create a second Studio for testing, and not realise that is the cause of some SourceLayers not existing. (at times I have had 2 studios defined in my dev environment to check they don’t interfere with each other) We have seen a similar problem in the past when not considering showstyle variants correctly

This is certainly the easiest to implement on the sofie-core side, but it leaves a lot of unused complexity and makes it harder in blueprints.

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

[nytamin]

Thanks for this RFC!

We (the NRK team) are in favor for eventually going with option 1 (limiting Sofie to only have 1 Studio). We don't see ourselves needing to run multiple studios from the same Sofie-instance in the future, so reducing the complexity would be beneficial long term.

That being said, if any other Sofie user reading this is of another opinion, please add your thoughts to this thread!

[jesperstarkar]

On behalf of EVS Broadcast Equipment

Thank you for this RFC!

The EVS team has voted in favor of Solution 1, as we believe it simplifies this part of the system.
We don't foresee any realistic scenario where multiple Studios would be needed within a single Sofie instance.