Resource icon

Source Defaults 1.1.1 test

AaronD

Active Member
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.

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

Member
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

Active Member
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.

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

Member
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

Active Member
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.

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

Member
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.

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

Active Member
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!

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

Active Member
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:

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

Member
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.

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

Active Member
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)

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

Member
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

Active Member
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:
 

CodeYan

Member
CodeYan updated Source Defaults with a new update entry:

v1.1.1 - Support adding a custom prefix to new sources

Add source name prefix by @CodeYan01 in https://github.com/CodeYan01/source-defaults/pull/5
  • This adds a prefix to sources of the same type, which can help to sort sources, especially when you have to choose from a dropdown of sources. Note that source name settings will only be applied after the source is actually created.
  • Thanks to @JoqniX from the OBS Discord Server for this suggestion!

Read the rest of this update entry...
 

CodeYan

Member
@AaronD thought i'd ask for feedback since the last time we talked about this plugin. Has the plugin been fine on your end? Any issues or suggestions?
 

AaronD

Active Member
@AaronD thought i'd ask for feedback since the last time we talked about this plugin. Has the plugin been fine on your end? Any issues or suggestions?
I hadn't really noticed, which probably means it's doing its job and not misbehaving. :-) Just toss stuff in, and it "just works" with all the correct settings for my rig. Thank you again for making it!
 
Top