persistent scenes

[techfueled]

Are there (or can there be) plans for persistent scenes? This would solve many issues, headaches, and save users an insane amount of time with fairly minor implementation requirements. Allow me to paint a picture to explain.

Currently we have Scene Collections to house different scenes containing sources. This is amazing in itself, but things get very complicated quickly when trying to do anything not basic.

When creating a scene, you have decoration sources (framing, background, etc) but when you jazz them up a little and add moving parts and ideas they begin to get complex. Lets say you have multiple scenes that you want to use. You can define them all in a single scene collection, but adding moving and changing parts grows your scenes and / or sources list complexity. Soon your lists begin to get intimidating and even daunting if not challenging to organize and utilize easily, ending up with duplication of assets and eventually mass confusion.

A great way around this is to utilize scene collections, however when you switch to a different scene collection it is initially empty, which is good, but there are many things you will probably utilize that you have already defined in another scene collection that now must be recreated, reconfigured, copied, and interacted with differently via tools such as stream deck for example.

The current approach to keeping things similar are to define these "resources" that will be reused in a "template" scene collection, and when you go to create a new scene collection you create it as a duplicate of your "template" and then add your new scene "decorations", etc.

When your "resources" change periodically, you have to change them in a certain place, then update your "template" collection, switch to it and remove excess scenes and sources that should not be in the "template", and still manually add the changes into scene collections that can not simply be "updated" easily.

I designate certain scene and source elements as "decorations" to help distinguish them from "content" sources for this conversation.

"Content" sources for creation can cover a various bunch that could easily be considered persistent sources, or things that will be reused regardless of scene "decorations".

Examples of "content" sources in this context could be but are not limited to:

• Video input devices (cameras)
• Audio input devices (microphones)
• Application inputs (e.g. capture web browser video and audio)
• Game inputs (e.g. capture the game being played video and audio)
• Communication inputs (e.g. discord, zoom, also technically application inputs by I wanted to list them for illustration)
• Branded background images / videos (default if nothing else is displaying for frames, seconds, or more)

These are some examples of content routinely recreated or linked in different scenes and collections. I'm confident most people could understand and even think of items unlisted here using the examples that were listed.

When OBS populates the list of "scenes", a secondary population of "persistent scenes" could easily enough be merged into the list before being displayed, listed, or rendered, as they would have the exact same properties and attributes. This would theoretically not damage nor break anything current since it is an identical merge at a few steps. The listed persistent scenes could populate on the same scenes list, difference being a "persistent" attribute being flagged, or perhaps the scenes list could have tabs for "collection" and "persistent" providing access separately. Perhaps the "persistent" scenes could simply be a reserved or designated scene collection.

Standard scenes created could then include the "persistent" scenes, for example camera and microphone. Control devices such as stream deck could toggle visibility of "persistent" scene source instead of standard scene source, ensuring that if you toggled the camera for example it would maintain its state among scene switches and even scene collection switches.

This minor change would cover large ground in terms of scene and source management, time management, and more. I would happily contribute the work myself if I were more confident in visual studio development or had a way to spin up on OBS Studio development quicker and easier than what I have viewed to date.

I hope I have accomplished my goal of communicating my thought clearly and in an understandable fashion and I hope it to gain community consideration as I do believe it would be a relatively easy path to massively enhanced operability.

I was told in a mistaken post on github that this exists and is called "Downstream Key", and while that is a nice feature / plugin, it does not fit what I am describing even slightly.

Thank you for your time.

 

[AaronD]

You're thinking of "software inheritance"? A base class, or in this case a base scene, is only partially defined, with only the things that are common to a set of child classes, or scenes. The children add their own specifics, and only their own specifics, because they already have everything that the parent has. Changing the parent, thus changes all of the children automatically, because there's only one copy of that in the first place, which is in the parent.

Multiple inheritance is possible too, where a child gets stuff from multiple parents, plus its own (if any). The pitfall there is called "the dreaded diamond", where you also have multiple levels of inheritance:

1. Grandparent
2. Multiple children of that grandparent
3. A child of two or more in level 2

If you draw that out, with arrows to signify the inheritance from one to another, you get a diamond shape. The way that most software tools handle inheritance is simply to copy all of the parents, one after another, and then add the child-specific things after that...but that results in *two* copies of the grandparent. Later stages in the build process really don't like that, because they don't know which copy to use. OBS would need a better way to handle that if non-programmers were to use it. (even programmers have difficulty with it sometimes)

---

Instead of that, what if you had fewer scene collections and more scenes in a single collection? Then you could have partial scenes that are never shown directly, but used as scene sources in other scenes. Almost the same idea, with almost the same pitfall, but it doesn't crash because rendering the same thing twice is perfectly legal, albeit inefficient.

 

[techfueled]

Yes I believe you are on the right path but perhaps I haven't been clear enough (as I have found in the mistaken post on github).

Lets say currently OBS performs a "GetScenesList" request and uses the resulting response to populate the "Scenes" list, or the "Current Scenes Selector" for nesting a scene, or for actual rendering. If there were either a special category that held the same data internally, or maybe a designated Scene Collection that could also be scanned and merged into the resulting ScenesList before listing / rendering, etc, this could be accomplished without issue theoretically. The reason being the special list or designated persistent list of course could include its own scenes, but it would be unnecessary to allow it to include scenes from other collections.

Any other scene collections could also have access to the scenes defined in the persistent list due to the merging before display / list / render as if they were its own scenes. The necessary checks to perform would be unique naming and assets within the scene collection, as it already is, but due to persistent scenes having already been merged into current scene collection upon load they should function the same to avoid issue.

Here is an example of current usage to help clarify the idea:

Lets say I have a scene called "Feature" that includes scenes "Apps" and "Games" and a source for "discord audio".

Within the "Games" scene let's say I have a few games configured, and the same within the "Apps" scene. Sometimes I'm featuring a certain game, sometimes I'm featuring a certain application, sometimes I'm featuring alternate games or apps. Regardless of what I'm featuring, I use different scene designs to feature them. I have stream deck buttons that toggle the active "game" or "app" as well as overall visibility of "games" scene or "apps" scene within "feature" scene, not the active scene. Doing this applies my desired state to all scenes holding the "feature" scene.

When I make a new scene collection, I make it from a copy of the template scene collection with the described basic scenes, yes. The issues arise when changes need to be made to the base template scene, or when (like recently) OBS dumps all of my scenes and collections and settings and reinitializes as new and I have to recreate everything not recently backed up.

It would be much nicer and easier if the "persistent" scenes "feature", "games", "apps", etc. lived in a single area yet were still able to be included into other scene collections so if something needed to be resized, reconfigured, etc for whatever reason it could be done in one place and would apply across all scene collections and scenes that use them. Currently when this need arises I am required to make the same tweak(s) in many places because the scenes have to exist in all scene collections and without the scene collections the scenes list gets far too long to use and manage.

 

[AaronD]

So the scene *collection* inherits another scene collection? Otherwise the same idea?

 

[techfueled]

So the scene *collection* inherits another scene collection? Otherwise the same idea?

Specifically set, either within the application or configured within application settings to make sure the issues you described don't occur as well as for simplicity. Correct.

 

[AaronD]

So instead of each scene collection potentially inheriting from a different collection (its list of parents is in the collection, and can be different), you have a single collection as a single parent for all others. And which one that is, is a global setting.

One problem I can see with that, is if you have a scene source that crosses the boundary between the local collection and the new global one, in either direction, and then you change the global setting. Now that scene source breaks.

 

[tripletopper]

I'm having similar problems having a separate 2D full color version of scenes and a 3D monochromised anaglyph version of those scenes. If I apply color filters to the child scene it also affects the parent. So that I have to manually turn off and on the color filters every time I want to switch between 2D and 3D instead of 3d being always right in cyan and 2D always being full color.

 

[AaronD]

I'm having similar problems having a separate 2D full color version of scenes and a 3D monochromised anaglyph version of those scenes. If I apply color filters to the child scene it also affects the parent. So that I have to manually turn off and on the color filters every time I want to switch between 2D and 3D instead of 3d being always right in cyan and 2D always being full color.

I think that's a different problem. I think you've duplicated a source in multiple scenes, so OBS only actually has one copy of that source with all of its direct filters. If you change one of those filters, then that change affects all of them. Almost like the above, but subtly different.

Instead, you could use the Source Clone plugin, to have different filters for each:

Source Clone

Add source to OBS that lets you clone sources to allow different filters than the original

obsproject.com

Or, have that source in its own scene, without that filter, and then use a Scene source everywhere that you want to copy it, with different filters on each of the Scene sources. I *think* that works; haven't actually tried it.

 

[tripletopper]

I tried the second option making the parts I want changed to be a scene and then changing the scene on other scenes but when you change the one main scene even though it's on the child scene it carries over to all versions of that scene.

 

[AaronD]

Well, I guess that doesn't work then. There's still the Source Clone plugin. Does that do what you need?