persistent scenes

[instantdata]

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.

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.

Thank you for your time.

[Fenrirthviti]

This is known as a Downstream Key, or DSK, and is available as a plugin already here: https://obsproject.com/forum/resources/downstream-keyer.1254/

And is suggested as a native feature here: https://ideas.obsproject.com/posts/70/ui-for-dsk-audio-interface-channels

Please keep ideas/feature requests to our ideas site, we do not want to use GitHub discussions for those. Make sure to read any pinned posts in Discussion boards before posting.

Thanks!

[instantdata]

According to the video on the downstream key plugin page you linked, you must create a scene, select it, and then click the "+" icon in the DSK panel to add it as a downstream key. Doing this would include it in the downstream key panel, and if you select it within that panel it will overlay it on top of the active scene.

This is very useful for doing that, like the demonstrated lower third, but it doesn't show the ability to change scene collections and use them in other active scene collections once created, and even if it did, that is not what I'm describing.

Imagine a scene called "Web Browser" to be basic. It captures your designated web browser. That is all it does. You may have a "Scene" that shows you in a theater looking at a screen and want your web browser to appear to be what is on the movie screen. This "Scene" may actually be a "Scene Collection" you switched to, but you still want to see your "Web Browser" in an included scene. Instead of reconfiguring a new "Source" or "Scene" for your web browser, it could be included from your already defined persistent scenes. Doing this would allow you to interact with that predefined persistent scene regardless of the scene you were viewing it from.

Perhaps you have another "Scene" that looks like you are outdoors and seeing your web browser in the sky on a blimp. This could be another scene collection that includes the persistent web browser (or whatever, camera, etc.) and you may have other scenes that you want to use between the outdoors and the blimp.. switching between the scenes you still want the same persistent content just displayed differently in separate scenes or scene collections.

I hope that clarifies better.

[Fenrirthviti]

I believe we are talking about the same thing still. The plugin limitation of not allowing global (i.e. across collections) is simply an implementation detail, more than a specific restriction. Having a global DSK that can be used exactly as you describe it in multiple collections is part of the eventual design I would like to see.

[instantdata]

I can show you in screen captures what I do currently if you like that maybe would make it easier to illustrate that we aren't really talking about the same thing from what I can tell. I don't know if you're interested enough to see them and I feel bad because you literally told me to not post this stuff here yet we are having a conversation based off of my suggestion in the manner I envisioned upon initial post.

If you like we could move / continue this conversation on the ideas forum where I reposted the original post.

Until then for further clarification, 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.

[Fenrirthviti]

The conversation is already happening here, so it's fine, but I understand what you're asking for perfectly well. You're effectively just using nested scenes, and you want to be able to update the nested scene across multiple collections without having to edit each one individually.

That is exactly what I'm talking about. It's not possibly currently, yes, but it's part of an eventual end-goal for a DSK feature. You'd have a "global" DSK that could be added to any scene, in any collection, anywhere in OBS. Updating the "master" version of this in the list of DSKs would send those changes elsewhere. I'm unsure where the disconnect here is, we've been talking about the same thing this entire time. A DSK doesn't have to only be used for lower thirds. In the context of OBS, a DSK is just a nested scene that's persistently applied to where you want it to be.

EDIT: I guess if we're being super pedantic, a DSK does technically imply "always on top" but there's no reason it couldn't be added/moved/positioned as any other kind of source.

[instantdata]

Yes that is my concern exactly on why the suggested DSK doesn't fit the need technically. Inclusion of the DSK seems to contain sizing and positioning, as it is not a scene source.

What I am describing is dependent on designated sizing, positioning, and ability to be overlayed (not always on top) by other sources or scenes depending on the scene you are including it in.

To me the two concepts seem very different.