Resource icon

Advanced Scene Switcher 1.25.5

Rozenman

New Member
@Warmuptill, et. al.

Before I jump into a rather detailed set of questions I'd first like to say I greatly appreciate Adv Scene Switcher, and the time and effort you've obviously put into it.

[...]
I think I know what you need. Look. This won't solve your problem specifically, but it's a general principle:

Macro 1 by date starts something, does something.

Macro 2 by date starts something, does something.

Etc.

Then, a separate macro works like this:

If Macro 1 or Macro 17 or Macro 328 is true, then load such and such a stream key into a variable.

Example in the picture. Sorry for the non-Latin text here and there.
 

Attachments

  • Advanced Scene Switcher - 1.25.5 2024-05-02 20-46-15.png
    Advanced Scene Switcher - 1.25.5 2024-05-02 20-46-15.png
    228.4 KB · Views: 4

Warmuptill

Active Member
But..., if "Perform actions only on condition change" is enabled, Adv. Scene Switcher doesn't always run a macro triggered only on day of week (my guess is that if Adv. Scene Switcher isn't running when the day of week actually changes at midnight, it doesn't recognize the macro hasn't fired yet when OBS starts on a different day).
The macro should be still be executed at least once when the plugin is first started.
The plugin does not need to "witness" the day actually changing.

You should be able to verify this with such a test macro:
1714674052677.png

And checking the value of the variable after starting the plugin on the variable tab:
1714674090706.png


If this *does not* work this would definitively be unintended behavior.
In that case I would be very interested in what you have configured so I can fix it.
You could share the setting by exporting them to a file.

If "Perform actions only on condition change" is not set, there is no reliability issue because the macro is running every 300ms, 100% of the time -- which is almost certain to occur before the livestream startup macro is initiated by hotkey. But..., having a macro run 3x a second 100% of the time just to make sure a variable is set accurately based on day of week, doesn't seem like a particularly clean/elegant approach.
The performance impact of those date checks / variable assignments should be minimal. (Just in case that is one of your concerns.)
But as mentioned before I think the approach with having "Perform actions only on condition change" enabled should work unless something is broken.

  • Having a way to set Adv Scene Switcher variables to a program's stdout output (so we can call PowerShell to produce a needed value).
  • Or, a way to set Adv Scene Switcher variables to a program's exit code
This should be possible already thanks to @Destroy666! :)
1714674799808.png


Before I jump into a rather detailed set of questions I'd first like to say I greatly appreciate Adv Scene Switcher, and the time and effort you've obviously put into it.
❤️

From what I can tell the ability to do things conditionally within macro actions is currently a bit limited in this regard(?) -- unless I missed something?
glaring omissions compared to most programming languages, one of which is inline conditionals
It is indeed very limited.
I understand and agree fully that this would be very useful to have.
But I always have to weigh it off against the time I have available and restructuring / redesigning the plugin to support this is unfortunately not an option for me at the moment.

What I could maybe do without too much effort is to add some of that functionality to the "Macro" action which already lets you run the action of other macros.
1714675458766.png

Adding a checkbox to only perform those steps if the conditions of the selected macro evaluated to "true" might be quite straight forward.

At that point, why not add a python tab? It's already a mature language with a TON of features in addition to this, and lots of existing documentation and tutorials, and designed for beginners to pick up quickly and "just use". Each condition would then be a function with arguments/parameters that returns true or false, and you'd put them in your own if's and use python's logic to combine them. Actions would also be predefined functions in the new Adv. SS library...

A "code generator" might be useful as well, mostly to discover what exists to be able to use, and that could be heavily based on the existing GUI. Just limit the generator to one condition or one action, and a button to either put on the clipboard or insert at the cursor, the function call that corresponds to what it's set for at that moment.
It is a great idea and sounds like fun project but I simply lack the time to implement this.
But I do appreciate the suggestion nonetheless! :)
 

AaronD

Active Member
restructuring / redesigning the plugin to support this is unfortunately not an option for me at the moment.
Yes, it would be a lot of work to add that functionality into the format that presently exists. Hence the completely different format, and the note that that different format already exists, so why not use that.

Keep the GUI, mostly as-is - maybe even simplify it: remove the more confusing parts, or the harder things to maintain - and have it be a "Lite" version that is still graphical. Easy to use, and kept that way. Intentionally limited to avoid confusion. Then have the python tab that can do absolutely anything at all, but requires knowledge of python (and in the more complex cases, software management) to do it.

If you do *remove* functionality though, then you'd need a migration tool that converts an old macro into an equivalent chunk of python code. Given the limited nature of the macros by comparison, that shouldn't be *too* hard once you get going, but it's not trivial either. Good design up front would make a big difference, and would almost certainly become a tradeoff between up-front translation, and ongoing ease of use and maintenance.

(Mile-long string of parameters in a single function, vs. several functions to build up an underlying state that is used by the final function, for just one example. The latter of those options would probably be more readable, and allow keeping the same state across many "final" uses, not that the automated translator needs to know about the reuse. It can rebuild the state every time, and I'd call that "okay".)

Generally, it's a good amount of work up front, for hopefully a lot less work later if you do it right! New functionality, if you want it to appear in both places, then involves the GUI once, and the underlying code once. Both are inherited by both tabs, in different ways: the macros as they are now (possibly with the "complex software" functionality removed), and python as the code generator and library function(s).

What I could maybe do without too much effort is to add some of that functionality to the "Macro" action which already lets you run the action of other macros.
View attachment 103632
Adding a checkbox to only perform those steps if the conditions of the selected macro evaluated to "true" might be quite straight forward.
That would be a good workaround at the moment, if you're really against the python tab.

But I think there'd have be *two* separate macro selections. One to run the actions of and one to check the conditions of, not necessarily the same. That avoids a maintenance nightmare on the user's end, with a big pile of macros that all have identical actions and different conditions or vice-versa.

And it also solves the problem of these macros just running on their own, since they have both conditions and actions. Now they don't have to: conditions with no actions does nothing on its own, and actions with no conditions also does nothing on its own. Then use this new functionality in the Macro action to put them together.

Of course, if you only had a checkbox and not a second selection, the maintenance problem could still be lessened if all of the condition macros had a single Macro action, that pointed to the actual code to run, but that's getting pretty silly and convoluted. And they'd all have to be paused, and their conditions as checked in the Macro action would still have to work when they're paused.

Not that that wouldn't be a workable chip design, along with a C or higher-language compiler that sorts it all out for you in the background...but it gets pretty clunky on a "chip" that you're designing to be directly hand-programmable in assembly, as Adv. SS macros kinda are.

I'd still consider it to be a non-ideal workaround though, mostly because the complete conditions and complete actions are not directly visible next to each other in context. That's also a problem in other languages when you share behavior across different parts of the code: a poorly-named function (macro in this case) that's used everywhere leaves you scratching your head about what it does, and you have to go track it down and read its code to find out.
 
Last edited:
Top