# Source Defaults



## CodeYan (Nov 4, 2022)

CodeYan submitted a new resource:

Source Defaults - Configure a source to be your "default" source, copying properties, filters, etc, to new sources!



> Source Defaults for OBS Studio
> An OBS Studio Plugin that lets you set a source as a "default source". Created sources of the same type will get  the settings from the configured default source.
> 
> Installation
> Click the "Go To Download" button at the top of this page, and download the installer for your platform. For Windows, it is recommend to use the installer (ends with "-Installer.exe"), to prevent installation mistakes and make it easy to uninstall the...



Read more about this resource...


----------



## CodeYan (Nov 28, 2022)

CodeYan updated Source Defaults with a new update entry:

v1.0.1



> Fix not applying source defaults on media sources created by dragging-and-dropping videos onto OBS



Read the rest of this update entry...


----------



## AaronD (Dec 6, 2022)

Great plugin!  Thank you!

Does it matter if I add it as an A/V Filter or an Effect Filter?  It appears in both lists.  A/V seems to work at least.

Could you add Transform?  The default for that, until a video actually plays, is zero size in the top-left corner.  When it plays, it changes to the native resolution, which may not be the canvas size.  I want everything to be exactly full-screen regardless, and scale accordingly, which would be the "Fit to screen" transform, but I'm sure there would be other uses for it as well.


----------



## CodeYan (Dec 6, 2022)

AaronD said:


> Great plugin!  Thank you!


Thank you too!


AaronD said:


> Does it matter if I add it as an A/V Filter or an Effect Filter?  It appears in both lists.  A/V seems to work at least.


Doesn't matter. Added it to both since some sources only have audio, some only have video. I believe one Move Transition filter does this as well.


AaronD said:


> Could you add Transform?  The default for that, until a video actually plays, is zero size in the top-left corner.  When it plays, it changes to the native resolution, which may not be the canvas size.  I want everything to be exactly full-screen regardless, and scale accordingly, which would be the "Fit to screen" transform, but I'm sure there would be other uses for it as well.


I myself want this too, as I do have to fit to screen most of the time. The reason I did not add it initially is because of how sources vs. scene items are handled in OBS, as Transform is scene-dependent, whereas the already supported features in this plugin are scene-independent. Rest assured, I already have a plan on how to do this, so thank you for also stating that you need it, as it gives me a push.


----------



## AaronD (Dec 6, 2022)

CodeYan said:


> Transform is scene-dependent, whereas the already supported features in this plugin are scene-independent.


Hmm...that *would* be tricky.  Especially to keep the "obvious" (to me at least) workflow of having a Blackout scene that never goes away, with an empty source of each type just to set the defaults for those types.  To add new stuff, I just add a scene and then add a source, the usual way, and my custom defaults apply to what I just added.

Having not looked over the code as an end user, it seems surprising to me that the transform would be scene-dependent.  I would think that it should only depend on the canvas, which is a global setting.  Maybe a closer look would make it obvious, but it seems weird from here.

Keep up the good work!  And looking forward to seeing the Transform included too.  :-)


----------



## CodeYan (Dec 8, 2022)

AaronD said:


> Having not looked over the code as an end user, it seems surprising to me that the transform would be scene-dependent. I would think that it should only depend on the canvas, which is a global setting. Maybe a closer look would make it obvious, but it seems weird from here.


No, Transform is scene-dependent. Think about it. You can add a source in one scene with Fit to Screen, and in another, the same source can be smaller, or use Stretch to Screen. I would be glad to explain the details further but I don't want to confuse you with code if you are not familiar with the OBS API hahaha


----------



## AaronD (Dec 8, 2022)

CodeYan said:


> No, Transform is scene-dependent. Think about it. You can add a source in one scene with Fit to Screen, and in another, the same source can be smaller, or use Stretch to Screen. I would be glad to explain the details further but I don't want to confuse you with code if you are not familiar with the OBS API hahaha


I was thinking that each source in each scene was independent, to the extent that the Transform would work the same as the other settings.  Or are the other settings linked across scenes?  (put the same source in two scenes, look at their settings, change one, and see the other change too)  I haven't really tried.

At any rate, you don't really care about existing stuff do you?  Only new?  I would think that that would render the dependency problem moot anyway, unless there's something else I'm missing?

Not really criticizing so much as trying to understand.  Thanks!


----------



## CodeYan (Dec 8, 2022)

AaronD said:


> I was thinking that each source in each scene was independent, to the extent that the Transform would work the same as the other settings.


For example, properties of a source will be the same no matter if they are duplicated in a scene or in other scenes. Even if the layout is different, properties, filter, audio monitoring, etc, will all be the same on any scene. Transform is different because it is on a "scene item", not a source. You can have the same source in a scene, duplicated, with one placed on the left, the other on the right.

The scene-dependency that I was referring to was more about the code. To implement the existing features, the signal handler for source creation already gives the source, where I can modify those stuff directly. However, the source object that is given does not have access to transform. To get access to the transform, you have traverse all scenes (although you could start checking the current scene to account for most cases) and their scene items to find the source that was added. It's not that hard, I just have to find the time to work on it as I'm currently preoccupied with some stuff.


----------



## AaronD (Dec 8, 2022)

CodeYan said:


> For example, properties of a source will be the same no matter if they are duplicated in a scene or in other scenes. Even if the layout is different, properties, filter, audio monitoring, etc, will all be the same on any scene. Transform is different because it is on a "scene item", not a source. You can have the same source in a scene, duplicated, with one placed on the left, the other on the right.
> 
> The scene-dependency that I was referring to was more about the code. To implement the existing features, the signal handler for source creation already gives the source, where I can modify those stuff directly. However, the source object that is given does not have access to transform. To get access to the transform, you have traverse all scenes (although you could start checking the current scene to account for most cases) and their scene items to find the source that was added. It's not that hard, I just have to find the time to work on it as I'm currently preoccupied with some stuff.


Oh crud!  Yeah, I'd call that an oversight on OBS's side, to not specify the scene where a new thing was created.  It would have to *have* that information, so why not pass it on?

And it sounds like the same source in different scenes does have its settings linked, from what you describe, so that changing them in one scene would also change them in the other scenes.  I'm not sure whether to call that a feature or a bug, since I can see it being useful both ways.  I guess that's why there are two ways to Duplicate - Reference and Copy - though they're not always both available.


----------



## CodeYan (Dec 8, 2022)

AaronD said:


> Oh crud!  Yeah, I'd call that an oversight on OBS's side, to not specify the scene where a new thing was created.  It would have to *have* that information, so why not pass it on?


Well, it doesn't have that information, _scenes _do. See Jim's reply here https://discord.com/channels/348973006581923840/731208645848727593/1002227394737877083. I'd say it's more of a design decision, rather than an oversight, as this is not how filters were intended to be used, though Jim himself agrees that this is better user experience.


AaronD said:


> And it sounds like the same source in different scenes does have its settings linked, from what you describe, so that changing them in one scene would also change them in the other scenes.  I'm not sure whether to call that a feature or a bug, since I can see it being useful both ways.  I guess that's why there are two ways to Duplicate - Reference and Copy - though they're not always both available.


That's definitely a feature. I use it in many ways.


----------



## AaronD (Dec 8, 2022)

CodeYan said:


> Well, it doesn't have that information, _scenes _do. See Jim's reply here https://discord.com/channels/348973006581923840/731208645848727593/1002227394737877083. I'd say it's more of a design decision, rather than an oversight, as this is not how filters were intended to be used, though Jim himself agrees that this is better user experience.


I meant that the callback when a new source is created should also include the scene that it's on.  Then you don't have to search for it.  That's the oversight.

I don't have a Discord account, so I can't see the reference.  Can you copy/paste, perhaps?  Thanks!


----------



## CodeYan (Dec 9, 2022)

AaronD said:


> I don't have a Discord account, so I can't see the reference. Can you copy/paste, perhaps? Thanks!


----------



## CodeYan (Dec 9, 2022)

AaronD said:


> I meant that the callback when a new source is created should also include the scene that it's on. Then you don't have to search for it. That's the oversight.


You do have a point, but I'd say that's more because scenes, transitions, and filters are also considered sources in the backend, which do not necessarily have to be added to a scene. The signal handler for source creation is called when these are created, not just the input sources. So considering all these in mind, simplicity is better.


----------



## AaronD (Dec 9, 2022)

CodeYan said:


> ...scenes, transitions, and filters are also considered sources in the backend, which do not necessarily have to be added to a scene. The signal handler for source creation is called when these are created, not just the input sources. So considering all these in mind, simplicity is better.


Oh.  Okay.  But as I've seen in building media systems (sound, lighting, video, etc.), "simplicity" becomes highly deceptive because of the irreducible complexity of what it's trying to be.  You can move the complexity to where you don't normally see it, but you can't get rid of it.  And if you move it too far from where it normally wants to sit, you have to add *more* complexity overall just to make it appear "simple".  (a manager/wrapper, for example)

When a project doesn't do much to start with (app, media rig, whatever), it seems like a good idea to go a certain way, then as it grows, a different way becomes more natural but there's a lot of legacy stuff with hard connections to the old way.  (including cognitive rigidity of the operators, who grossly abuse the word "simple" when they really mean "familiar", and subsequently abuse the principles surrounding real simplicity in their arguments)

It seems to me that OBS has reached that point.  That's a good thing, that means it's growing and becoming more useful to more people, but at some point it's going to need yet another major incompatible version (like from 27 to 28 broke some plugins), or slowly become an unmaintainable mess.  Not spaghetti code, but spaghetti data flow.  Slightly different, but the same idea.
I've been there myself with some of my own apps:
"Ooo!  That'd be a cool feature!  Now how do I get the data for it from where it is to where it's needed?..."  And I end up creating a new path through the entire object structure, touching almost every source file, just to support that one feature.

From that perspective, iterating through all the scenes and their contents looking for the one that you've just been given the handle for, doesn't seem all that bad.  But it could still be better if OBS would include the scene, which could be null, as part of the signal handler.


----------



## CodeYan (Dec 9, 2022)

AaronD said:


> Oh.  Okay.  But as I've seen in building media systems (sound, lighting, video, etc.), "simplicity" becomes highly deceptive because of the irreducible complexity of what it's trying to be.  You can move the complexity to where you don't normally see it, but you can't get rid of it.  And if you move it too far from where it normally wants to sit, you have to add *more* complexity overall just to make it appear "simple".  (a manager/wrapper, for example)
> 
> When a project doesn't do much to start with (app, media rig, whatever), it seems like a good idea to go a certain way, then as it grows, a different way becomes more natural but there's a lot of legacy stuff with hard connections to the old way.  (including cognitive rigidity of the operators, who grossly abuse the word "simple" when they really mean "familiar", and subsequently abuse the principles surrounding real simplicity in their arguments)
> 
> ...


I mostly agree, especially with including the scene, but it's not for me to say. I haven't contributed much yet to the OBS project to have a say in things. What's more, this is probably a very niche use case so I doubt OBS devs would approve of such breaking change with very little gain. Keep in mind that bigger plugin devs like Exeldro and Warmuptill have written bigger and more plugins so if this was actually something they needed, they would have asked for it long ago. Anyway, there's a function to retrieve the current scene, so that will let me skip iterating through all scenes like 99% of the time. The 1% is just from custom scripts doing their thing and adding sources to other scenes.


----------



## AaronD (Dec 9, 2022)

CodeYan said:


> Anyway, there's a function to retrieve the current scene, so that will let me skip iterating through all scenes like 99% of the time. The 1% is just from custom scripts doing their thing and adding sources to other scenes.


Ah!  Okay.  So it's not all *that* bad.

And yes, the relatively rare things that bite you when you don't account for them despite their rarity.  Been there too.  :-/
("It just worked, and now it doesn't!  What happened?!...Oh.")

Sounds to me like:

```
search current_scene
if found
    return current_scene
for all scenes
    search scene
    if found
        return scene
return null
```


----------



## CodeYan (Dec 9, 2022)

AaronD said:


> Ah!  Okay.  So it's not all *that* bad.
> 
> And yes, the relatively rare things that bite you when you don't account for them despite their rarity.  Been there too.  :-/
> ("It just worked, and now it doesn't!  What happened?!...Oh.")
> ...


yep, that's exactly the algorithm i'm planning to implement. just can't start right now since i've still got some deadlines to meet, and from my experience, even relatively small changes lead to long testing and debugging time hahaha


----------



## CodeYan (Dec 16, 2022)

started to work on it. well, i guess it isn't as easy as i thought. it's not just the new scene item that I don't have access to, but also the parent source. again, there's no way to retrieve the scene item of the source other than enumerating the scenes and sources, because a source can have multiple scene items. so i think one way we could do this is to have a scene selection in the Source Defaults filter option to select the scene of the default source


----------



## AaronD (Dec 16, 2022)

CodeYan said:


> started to work on it. well, i guess it isn't as easy as i thought. it's not just the new scene item that I don't have access to, but also the parent source. again, there's no way to retrieve the scene item of the source other than enumerating the scenes and sources, because a source can have multiple scene items. so i think one way we could do this is to have a scene selection in the Source Defaults filter option to select the scene of the default source


Ooohhh, I think that's right.  I think I do remember the same source in multiple scenes having the same filters too.  I had forgotten about that because I don't normally do things that way.  But yes, it is something that must be accounted for.

And I think I'd do it the way you described too.  While you're doing all this work anyway, what else would be useful to add, so that you only have to do it once?


----------



## CodeYan (Dec 17, 2022)

AaronD said:


> And I think I'd do it the way you described too. While you're doing all this work anyway, what else would be useful to add, so that you only have to do it once?


I'm not really sure what else, but I'm thinking whether i need to separate the options for copying Transform stuff, like position, crop, etc. Personally I don't think I need to separate them. Just have a "Transform" option and that will copy the bounding box size and crop, similar to what the "Copy/Paste Transform" on the context menu does.

I guess this method would also allow automatically hiding the new sources as the sceneitem visibility is also sceneitem-based, though i'm not sure if that's going to be useful. There also might be a short time interval before it gets hidden.

Also, I might have to make "Copy Transform" default to off.

Thoughts?


----------



## AaronD (Dec 18, 2022)

CodeYan said:


> I'm thinking whether i need to separate the options for copying Transform stuff, like position, crop, etc. Personally I don't think I need to separate them. Just have a "Transform" option and that will copy the bounding box size and crop, similar to what the "Copy/Paste Transform" on the context menu does.


I've been bitten before, by thinking that I could lump things together, and then later finding a need to separate them.  I don't see a reason either, at least not at this moment, to separate the Transform options, but, you know......

Maybe you could have an overall checkbox that disables the individual ones?  Even if overall defaults to off, the individuals should probably all default to on.



CodeYan said:


> I guess this method would also allow automatically hiding the new sources as the sceneitem visibility is also sceneitem-based, though i'm not sure if that's going to be useful. There also might be a short time interval before it gets hidden.


Similar here.  I don't see a need at this moment, but......

A short time interval is probably okay, depending on how long it really is.  Longer if you put a note to that effect next to the checkbox.


----------



## CodeYan (Dec 18, 2022)

AaronD said:


> I've been bitten before, by thinking that I could lump things together, and then later finding a need to separate them. I don't see a reason either, at least not at this moment, to separate the Transform options, but, you know......


I'm inclined right now to just combine them for simplicity. having too many checkboxes is not very good. besides, i think having a copy of transform with crop is already pretty much a good default. I think if you have to copy only one aspect of transform, you'd likely just change the transform on your own too afterwards. But I'm open to adding it if there's demand.

I think I'll try adding the visibility to the options.



As I wrote more code, I realized an important fact that might make this impossible. When the source created signal is emitted, it isn't added yet to the scene lol.


----------



## AaronD (Dec 18, 2022)

CodeYan said:


> I'm inclined right now to just combine them for simplicity. having too many checkboxes is not very good. besides, i think having a copy of transform with crop is already pretty much a good default. I think if you have to copy only one aspect of transform, you'd likely just change the transform on your own too afterwards. But I'm open to adding it if there's demand.
> 
> I think I'll try adding the visibility to the options.


Okay.  We'll see what happens I guess.  Don't paint yourself into a corner.



CodeYan said:


> As I wrote more code, I realized an important fact that might make this impossible. When the source created signal is emitted, it isn't added yet to the scene lol.


Uhhh...hmm.  That makes things harder.

Could you set a timer, maybe?  Do everything you can immediately and set some notes, then a second later or so, use those notes to finish?
I did that for the focus control in a PTZ camera controller: read the entire preset and save the fixed focus (if present) to a variable, then 3 seconds later (roughly the time to finish moving), set the focus from that variable.

Or instead of a timer, is there another signal that you could catch?  Not for its intended purpose, but just because it's emitted after the source is added?


----------



## CodeYan (Dec 19, 2022)

AaronD said:


> Could you set a timer, maybe? Do everything you can immediately and set some notes, then a second later or so, use those notes to finish?
> I did that for the focus control in a PTZ camera controller: read the entire preset and save the fixed focus (if present) to a variable, then 3 seconds later (roughly the time to finish moving), set the focus from that variable.


Yeah, that's what I'm planning to try next. i'll try maybe a 0-second timer to see if the scene will be available by then. 

Another thing that i can try is to attach a signal handler on the current scene on the sceneitem added signal, but that would mean i'd only attach the signal handler to one, because attaching it to all scenes is a major PITA. this means that user plugins/scripts that would add new sources to scenes that are not in focus will not be supported.


----------



## AaronD (Dec 19, 2022)

CodeYan said:


> Yeah, that's what I'm planning to try next. i'll try maybe a 0-second timer to see if the scene will be available by then.


Zero time, to me, screams "Race condition!"  Maybe an asynchronous event queue always has what you need by then, or maybe not, or maybe a synchronous event queue never does.  Maybe an optimizer sees "zero time" and turns it into a thread fork.  Anyway, I'd use something finite for that.  Small is okay, but not zero.



CodeYan said:


> Another thing that i can try is to attach a signal handler on the current scene on the sceneitem added signal, but that would mean i'd only attach the signal handler to one, because attaching it to all scenes is a major PITA. this means that user plugins/scripts that would add new sources to scenes that are not in focus will not be supported.


I'm on the fence about that one.  I can see complaints about custom defaults not applying to automatically-created stuff, but also, presumably, the automatic stuff can set all of that on its own, so that the answer to those complaints would be to do it that way.

Of course, if the real difference is "current scene" or not, then it could open up another can of worms if the custom defaults are *sometimes* applied to automatic stuff (that just happened to be on the current scene at the time) and sometimes not.  If you're guaranteed to ignore what happens on not-current scenes, is there also a way to ignore an automatic addition to the current scene?

And what is the "current scene" anyway?  Is it the one shown to the audience?  'Cause I can manually edit a different one than that.


----------



## CodeYan (Dec 19, 2022)

AaronD said:


> If you're guaranteed to ignore what happens on not-current scenes, is there also a way to ignore an automatic addition to the current scene?


That does not make sense, as in the first place the plan was to monitor the current scene for the addition. whether or not a source was created manually (by the user) or automatically (by a script/plugin) is not distinguishable.



AaronD said:


> And what is the "current scene" anyway? Is it the one shown to the audience? 'Cause I can manually edit a different one than that.


Current scene would be the preview scene. if you're in studio mode, that would be the one you're editing.


----------



## AaronD (Dec 19, 2022)

CodeYan said:


> Current scene would be the preview scene. if you're in studio mode, that would be the one you're editing.


That's what I was thinking too...until I thought of Adv. SS's (relatively) new condition that looks at Any Media on Current Scene.  I really hope that's a case of two different definitions for the same term!



CodeYan said:


> That does not make sense, as in the first place the plan was to monitor the current scene for the addition. whether or not a source was created manually (by the user) or automatically (by a script/plugin) is not distinguishable.


If I have 2 scenes - A, B - and a script somewhere adds something to scene B, would you apply the custom defaults if I were previewing scene A?  What if I were previewing scene B when the script ran?  If those two answers are different, that's the problem that I was pointing out.

I don't expect to have that problem, because I don't add or remove things automatically.  (not a principle thing; just how my workflow ended up)  But I'm sure that someone somewhere does.

The "guarantee" as I said then, is the result of a choice to not search all scenes.  Not a hard guarantee that can't be worked around.


----------



## AaronD (Dec 19, 2022)

Slightly off-topic, but may still affect you:
I've just now come to understand a deal-breaker problem on my end:  It appears that NVIDIA has abandoned their older hardware - stopped releasing drivers for them - including mine, and OBS v28 removed support for the older drivers:





						OBS 28.0.3 is the latest that works right on my laptop. Newer ones will not use my NVENC encoders.
					

I had to uninstall the latest OBS STUDIO release, and download the older OBS 28.0.3 Focal release debian package and install it. The newer ones sudenly will not use my NVENC encoders in my NVIDIA GK104GLM [Quadro K4100M]. Yes I know it's and older NVIDIA card, but it's a laptop, so I cannot...




					obsproject.com
				








						OBS 28.0.1 can use the old QSV encoder but not the old NVENC encoder?
					

My NVIDIA graphics card is relatively old (GeForce GT 735M) and has been updated to the latest version of the driver. The previous version 27.2.4 of OBS Studio can use hardware NVENC encoding. Yesterday, I received an update prompt. After the upgrade is completed as required, start the software...




					obsproject.com
				




It still works just fine...so long as I don't try to stream or record.  So I didn't notice that problem lurking in the background as I was testing the new features that I requested in Adv. SS.

Since this only affects older hardware - people with newer machines won't notice anything wrong - how much of a pain would it be for you to support both pre- and post-break versions of OBS?


----------



## CodeYan (Dec 20, 2022)

AaronD said:


> If I have 2 scenes - A, B - and a script somewhere adds something to scene B, would you apply the custom defaults if I were previewing scene A? What if I were previewing scene B when the script ran? If those two answers are different, that's the problem that I was pointing out.


If script creates a source on scene B, and scene B is being previewed, custom defaults would apply. If not previewed, won't apply.



AaronD said:


> Since this only affects older hardware - people with newer machines won't notice anything wrong - how much of a pain would it be for you to support both pre- and post-break versions of OBS?


The way I understood that was 28.0.3 works but not later OBS versions? In that case, it would work for both versions as my plugin is built based on OBS 28


----------



## AaronD (Dec 20, 2022)

CodeYan said:


> If script creates a source on scene B, and scene B is being previewed, custom defaults would apply. If not previewed, won't apply.


I can see that being confusing for someone that doesn't understand the internals.  Not something that they're likely to figure out beyond, "sometimes works, sometimes doesn't."  I think it would be more consistent to wait (somehow) until it's been added to a scene, and then search all scenes.

If you could tell the difference between manual and automatic additions, then you could just ignore the automatic ones and be done.  But since OBS doesn't give you that information, I think the consistent thing to do from a user's perspective is to find it wherever it is, and apply the custom defaults regardless.

From what you've said so far, I think the way I'd look at doing it is to have just the one handler on the source created signal, and that's it.  It's not in a scene yet at that point, so set a 0.1-second timer or so (not zero), and when that timer goes off, search all scenes.
(100ms should be fast enough for a user to not notice, and still "forever" in terms of code running)



CodeYan said:


> The way I understood that was 28.0.3 works but not later OBS versions? In that case, it would work for both versions as my plugin is built based on OBS 28


I replied to one of those threads (forgot which), saying that I tried an early v28 and it still didn't work.  I think the actual break happened between major versions.


----------



## CodeYan (Dec 20, 2022)

AaronD said:


> I replied to one of those threads (forgot which), saying that I tried an early v28 and it still didn't work. I think the actual break happened between major versions.


That's a bit of a problem. Perhaps I'll ask warmuptill how to build for v27 as well, as the plugin template only builds for 28 and up.


----------



## AaronD (Dec 22, 2022)

CodeYan said:


> That's a bit of a problem. Perhaps I'll ask warmuptill how to build for v27 as well, as the plugin template only builds for 28 and up.


I got OBS 28 to work!  Thanks for the effort anyway.

What I was seeing before was actually a problem with FFMPEG, not OBS, which was solved by updating the NVIDIA graphics driver from 390 to 470.  That then killed the laptop screen, which required a BIOS setting to fix.

A little bit more tweaking also got OBS 28 to work.  Details here:





						OBS 28.0.3 is the latest that works right on my laptop. Newer ones will not use my NVENC encoders.
					

I had to uninstall the latest OBS STUDIO release, and download the older OBS 28.0.3 Focal release debian package and install it. The newer ones sudenly will not use my NVENC encoders in my NVIDIA GK104GLM [Quadro K4100M]. Yes I know it's and older NVIDIA card, but it's a laptop, so I cannot...




					obsproject.com


----------



## CodeYan (Dec 22, 2022)

Yay! Less complexity on our end. Thank you


----------

