Advanced Scene Switcher 1.28.1

[lindenkron]

Thanks for pointing that out, but that is actually intended behavior!
The option to set "waitForTransition" was removed already in the last version as it did not really fit into this condition type. (Unticking this checkbox is basically equivalent to a "Transitioning to ..." check)
Existing conditions were not affected for compatibility reasons, but if you choose to set the "waitForTransition" field the option will be hidden.


But thanks again for having a look out for potential issues! :)

Okay, little confusing. Sorry for bringing it up, it just came across as a feature unintentionally disappearing.

So am I to understand it correctly that from now on you should never use 'scene' for anything that's supposed to happen once when going to a scene? That from now on If Transition Transitioning to SCENE should be used?

Personally feels a little unintuive to me from how I've used adv-ss previously, but hopefully it'll feel more natural in the future.

What's your intentional usage of the "If scene" functionality now then?

 

[lindenkron]

Hmm, having issues with this triggering multiple times and not having a time restraint condition

Is it not possible to use this?

 

[Warmuptill]

That from now on If Transition Transitioning to SCENE should be used?

No, you can still use the scene condition for current scene checks just like you did before.

Only the additional check of testing which scene is being transitioned to during an ongoing transition should now be done using the transition condition type.

Sorry if this is getting confusing - What are you trying to achieve exactly?

 

[Warmuptill]

Hmm, having issues with this triggering multiple times and not having a time restraint condition

Is it not possible to use this?

Good point - I will enable time constraint for this condition type.
A build with this change should be available here in a few:

Enable time constraints for transition condition · WarmUpTill/SceneSwitcher@1e08bed

An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.

github.com

 

[lindenkron]

I'm having real issues getting this to work properly using any form of Transition conditional. Currently using If transitioning from, it doesn't fire anything until after the transition is finished.

I feel like this is a very focal use case for adv-ss, changing things upon transitioning from one scene to another - and it bothers me a little that I'm having such a hard time figuring out the functionality.

I want to have these possibilities:
Going from scene A > B
Going from scene A > B starting after transition
Going to scene B
Going to scene B > starting after transition

In my head, if I forget all about how adv-ss works this is what I would be expecting UX wise:
If previous scene is X
If current scene is Y
check field - after conditions have been met, disable.

 

[Warmuptill]

I'm having real issues getting this to work properly using any form of Transition conditional. Currently using If transitioning from, it doesn't fire anything until after the transition is finished.

I feel like this is a very focal use case for adv-ss, changing things upon transitioning from one scene to another - and it bothers me a little that I'm having such a hard time figuring out the functionality.

Sorry about that :(
I probably misinterpreted the past discussion about the "wait for transition to complete" checkbox.

I want to have these possibilities:
Going from scene A > B
Going from scene A > B starting after transition
Going to scene B
Going to scene B > starting after transition

These setups should allow you to achieve what you are looking to do.

Going from scene A > B (during transition)
Going from scene A > B starting after transition
Going to scene B (during transition)
Going to scene B > starting after transition

In my head, if I forget all about how adv-ss works this is what I would be expecting UX wise:
If previous scene is X
If current scene is Y
check field - after conditions have been met, disable.

What exactly do you mean with "check field - after conditions have been met, disable."?
Do you want to disable the macro after it ran once or are you referring to time constraints?

The issue with just providing "If current scene is Y" is that it can mean multiple things while a transition is ongoing.
Assuming you are transitioning from A to B, the current scene could either be A or B, depending on your definition of "current scene".
(The scene being transitioned away from - as it is still active during the transition - or the scene being transition to)

 

[lindenkron]

What exactly do you mean with "check field - after conditions have been met, disable."?
Do you want to disable the macro after it ran once or are you referring to time constraints?

The issue with just providing "If current scene is Y" is that it can mean multiple things while a transition is ongoing.
Assuming you are transitioning from A to B, the current scene could either be A or B, depending on your definition of "current scene".
(The scene being transitioned away from - as it is still active during the transition - or the scene being transition to)

Let me first say a huge thanks for this post. I'll be going through each example to see what works for me in a few mins.

The check field would be for a way to stop the conditions from being met, after they've been met once. One of the things I run into most that breaks my things is a trigger running twice. This results in bat files being run multiple times, or vlc play lists being triggered over and over (obviously ruining their purpose).

I think one of the issues we're running into is programmer versus user perspective on things like ' "If current scene is Y" is that it can mean multiple things'. In my world, if I press/or change to a scene in OBS that's the 'current scene', whether or not we've transitioned there yet. In my OBS, it's highlighted. It also means, that the scene we're currently going away from, is the previous scene.

From the previous posts that was being talked about on here, it seemed to me like 'Transitioning' was put in place to replace 'If scene' logic, but I may have misunderstood things. At least it seems like anything you want to trigger immediately upon switching to another scene (regardless of the duration of transition) cannot be done with this condition.

What I often do, is use the duration of the transition to modify the audio levels and playlists. So it's important for me to be able to immediately upon changing scene, being able to start adjusting these things during transitioning.

Thanks once again, super appreciated as always.

EDIT:
Also, the aboved mentioned should only trigger once. I don't think your examples do, do they? I forgot to mentioned that, Sorry!

 

[Warmuptill]

The check field would be for a way to stop the conditions from being met, after they've been met once. One of the things I run into most that breaks my things is a trigger running twice. This results in bat files being run multiple times, or vlc play lists being triggered over and over (obviously ruining their purpose).

I see - that's a good point.
I implemented the requested functionality by introducing the following checkbox:

I think one of the issues we're running into is programmer versus user perspective on things like ' "If current scene is Y" is that it can mean multiple things'. In my world, if I press/or change to a scene in OBS that's the 'current scene', whether or not we've transitioned there yet. In my OBS, it's highlighted. It also means, that the scene we're currently going away from, is the previous scene.

From the previous posts that was being talked about on here, it seemed to me like 'Transitioning' was put in place to replace 'If scene' logic, but I may have misunderstood things. At least it seems like anything you want to trigger immediately upon switching to another scene (regardless of the duration of transition) cannot be done with this condition.

Yes correct, the intention was to move the transition related parts of the current scene check to the transition condition.
But that seems to have caused a lot of confusion.

I reintroduced a checkbox which allows changing the current scene check behaviour, but I have adjusted the wording to make its effect more clear.

A build with both of these changes should be available here in a few minutes:

Enable time constraints for transition condition · WarmUpTill/SceneSwitcher@4d6bd9d

An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.

github.com

Let me know if everything there works as expected and if the wording I used is somewhat clear.
If that should be the case I will make another release including these changes tomorrow.

Also, the aboved mentioned should only trigger once. I don't think your examples do, do they? I forgot to mentioned that, Sorry!

Ah ok - you could add a condition "transition ended" for the 2nd and 4th case and a time restriction for the 1st and 3rd case, but I assume the use of the newly introduced option "Perform actions only on condition change" from above is probably preferred.
Here is the updated table:

Going from scene A > B (during transition)	or or
Going from scene A > B starting after transition
Going to scene B (during transition)	or
Going to scene B > starting after transition

By the way I have started work on a wiki for this plugin (emphasis on started - not much there yet) :

Home

An automation tool for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.

github.com

If you have suggestions for topics to add there let me know or feel free to add something yourself.
I will try to update the transition page later if I find the time.

 

[lindenkron]

I see - that's a good point.
I implemented the requested functionality by introducing the following checkbox:
View attachment 78783


Yes correct, the intention was to move the transition related parts of the current scene check to the transition condition.
But that seems to have caused a lot of confusion.

I reintroduced a checkbox which allows changing the current scene check behaviour, but I have adjusted the wording to make its effect more clear.
View attachment 78784

A build with both of these changes should be available here in a few minutes:

Enable time constraints for transition condition · WarmUpTill/SceneSwitcher@4d6bd9d

An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.

github.com

Let me know if everything there works as expected and if the wording I used is somewhat clear.
If that should be the case I will make another release including these changes tomorrow.


Ah ok - you could add a condition "transition ended" for the 2nd and 4th case and a time restriction for the 1st and 3rd case, but I assume the use of the newly introduced option "Perform actions only on condition change" from above is probably preferred.
Here is the updated table:

Going from scene A > B (during transition)	View attachment 78787 or View attachment 78788 or View attachment 78789
Going from scene A > B starting after transition	View attachment 78791
Going to scene B (during transition)	View attachment 78792 or View attachment 78793
Going to scene B > starting after transition	View attachment 78794

By the way I have started work on a wiki for this plugin (emphasis on started - not much there yet:

Home

An automation tool for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.

github.com

If you have suggestions for topics to add there let me know or feel free to add something yourself.
I will try to update the transition page later if I find the time.

Legend. That 'perform actions only once' stops me from having to time restraint every condition! Amazing.

And the during transition check is nice. It'd been better to have a "Wait for transition" in my world and have it running during transition as default, this seems a bit backwards - but it works. I tested it, and I finally got the expected outcome of everything running during transitions and is neat. What are your thoughts on having it running during transition being default, and allowing people to have it 'Wait for transition'?

I'm using this one:

(Also, it says 'traget' not 'target' hihi :D)

 

[Warmuptill]

Warmuptill updated Advanced Scene Switcher with a new update entry:

Macro on change option, transition time constraints, and current scene transition check

Additions:

• Add option to perform macro actions only on condition change.
  
• Enable the use of time constraints for transition condition type.
• Reintroduce checkbox to change current scene check transition behaviour.

Read the rest of this update entry...

 

[AlixSkye]

What exactly have you configured?
If you don't mind you can export your current settings to a file on the General tab and attach it here.

I actually figured it out about 5 minutes after I posted this. I had to unmute certain outputs as well as muting the ones I wanted muted. Thank you so much for the reply! :D

 

[lindenkron]

Hey @Warmuptill

Is there currently a function to execute this button in adv-ss? I can't find it if there is

I can't find anything regarding browser sources in general. If so, is that intentional?

 

[Warmuptill]

Hey @Warmuptill

Is there currently a function to execute this button in adv-ss? I can't find it if there is
View attachment 78867
I can't find anything regarding browser sources in general. If so, is that intentional?

Could be that I am just missing something, but I don't think there is any API to invoke the refresh function "manually".
Maybe what could be done instead is tick the "refresh browser when scene becomes active button" and just quickly hide and show the source?

What exactly would you use this manual refresh for?

 

[lindenkron]

Could be that I am just missing something, but I don't think there is any API to invoke the refresh function "manually".
Maybe what could be done instead is tick the "refresh browser when scene becomes active button" and just quickly hide and show the source?
View attachment 78870
What exactly would you use this manual refresh for?

Worked around it by setting a hotkey in OBS hotkey to refresh the browser source, then invoke that hotkey with Adv-ss.

It's for refreshing a tournament bracket through streamdeck incase it for some reason gets stuck and doesn't update scores :)

 

[kineticscreen]

Warmuptill updated Advanced Scene Switcher with a new update entry:

Dock, OpenVR, and more

Thanks so much for creating the dock - makes a massive difference to usability. Is it possible to make the indication more clear, like with the Red and Green background as in the panel proper, or is that a limitation with OBS Docks?

 

[AaronD]

Worked around it by setting a hotkey in OBS hotkey to refresh the browser source, then invoke that hotkey with Adv-ss.

It's for refreshing a tournament bracket through streamdeck incase it for some reason gets stuck and doesn't update scores :)

I might have done it with an external browser in fullscreen behind OBS's control window, and window-capturing that. (Alt-TAB after setting fullscreen, to switch back to the previous window and get the taskbar back, and the window capture still works, even though it's behind something else) Then set the external browser to refresh itself every 10 seconds or whatever.

I use that structure for hybrid local / online meetings with media. The online meeting runs in an external browser, instead of a browser source, so I know it's going to stay active no matter what. Then I put it fullscreen *behind* OBS on the *control* screen and window-capture it in just one of three scenes. (the other two are for featured media with its own audio, and featured media with voiceover - that media comes from another instance of OBS that directly feeds the online meeting...)

 

[Warmuptill]

Thanks so much for creating the dock - makes a massive difference to usability. Is it possible to make the indication more clear, like with the Red and Green background as in the panel proper, or is that a limitation with OBS Docks?

Sure that can be done.
A build with this change should be available here in a few minutes:

Use the same widget for main settings window and status dock · WarmUpTill/SceneSwitcher@cf2aec4

An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.

github.com

As usual you will need to be logged into GitHub to be able to download this build - if that is an issue for you let me know.

The red pulse can be disabled in the settings window on the General tab via "Disable UI hints" in case it should become annoying.

 

[kineticscreen]

Very nice. Would like it if it were lit up as green when active, but that's just personal preference - don't know what's useful to more people, whether being alerted that it's OFF is more important, or seeing that it is active.

 

[AaronD]

...don't know what's useful to more people, whether being alerted that it's OFF is more important, or seeing that it is active.

That was the perpetual problem that we had when I was in industrial controls. Whether "green" should mean that you CAN turn it on, or that it IS already on? And for the other way, whether "red" should mean that you CAN turn it off, or that it IS already off? Also, looking at the control panel from a distance, does all-green mean that things are off and (somewhat) safe, or that they're all running correctly?

The (somewhat arbitrary) way that we solved it was to make everything drab except for a splash of bright color for the option / state that was presently active: red for off / fault, green for on / running / auto, yellow for maintenance / manual. So for us, all-green meant that things were already on and running correctly. YMMV.

 

[kineticscreen]

That was the perpetual problem that we had when I was in industrial controls. Whether "green" should mean that you CAN turn it on, or that it IS already on? And for the other way, whether "red" should mean that you CAN turn it off, or that it IS already off? Also, looking at the control panel from a distance, does all-green mean that things are off and (somewhat) safe, or that they're all running correctly?

The (somewhat arbitrary) way that we solved it was to make everything drab except for a splash of bright color for the option / state that was presently active: red for off / fault, green for on / running / auto, yellow for maintenance / manual. So for us, all-green meant that things were already on and running correctly. YMMV.

Yeah this is an interesting problem - I imagine it's even more complicated when it's the button itself that is changing colour - is it indicating the current state, or is it indicating the state the pressing the button will initiate? In this case it is at least just fairly obvious that it is an indication of the current state. My preference is that whatever it is, it makes it easy to glance and instantly know whether it is running or not.