@Warmuptill excellent thanks. it works, just an error does not update. In order to see the imported macro, you must close adv ss and then open ..A build with this functionality will be available here in a few minutes:
Export import · WarmUpTill/SceneSwitcher@4c02505
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.github.com
Here is the general work flow:
As usual with test releases - please make sure to back up your settings beforehand before trying them.
- Mark the macros you want to export and right click in the macro list to select the "Export" functionality.View attachment 96305
- Copy the contents of the dialog that pops up:
View attachment 96306- In the scene switcher instance / scene collection you want to import the macros in right click and select "Import".
View attachment 96308- Now paste the content you copied earlier in the dialog and click OK:
View attachment 96309
- The macros are now added to your macro list.
In case a name conflict with an already existing macro comes up you will e asked if you want to rename the new macro or skip its import.
And please let me know if you run into any issues! :)
(Pinging @biosmatrix as you were interested in this functionality also.)
Resource icon
- Thread starter Warmuptill
- Start date
Warmuptill
Active Member
Can you please share the steps / settings to reproduce this problem?
Unfortunately so far I was not able find the issue.
Now export
delete macro 2, close adv ss then open and import
and see
after importing, it does not show the content of the imported macro or of any other macro that has already been created previously
but when i close and reopen. there are the macros with their content
Is there a Windows command line that I can use to start the Advanced Scene Switcher with saved exported settings using Windows Task Scheduler?
The settings are included in the Scene Collection, and OBS has a command line switch for the entire collection. Maybe that's enough for you?
If you really want to load a different set of macros in the *same* Scene Collection, then you might put a macro in it beforehand that does that:
The condition shown here - "running" is always true, combined with the "only on change" checkbox - runs once on startup and never again. I use it to set up a bunch of things that could have been left any number of different ways, depending on what I did last session.
If you want the same scene collection to load another one on the next startup, then you need to make sure that the auto-load macro is also in the settings to load. A potential pitfall is if the "only on change" can re-trigger after loading, in which case it'll continue to load the new settings over and over and over again. Try it on a "sandbox" machine before you rely on it for production.
Warmuptill
Active Member
Ah sorry about that - I was too focused on the macro list that I did not even notice that the conditions / actions section was not updated.
A build with a fix should be available here in a few minutes:
Export import · WarmUpTill/SceneSwitcher@24b3c20
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
github.com
Yes, that is possible - I will add it to the next release.Also, is it possible to have some buttons to move macro events/actions to the Top + Bottom? I would in visage it like this:
A build with this change will be available here (but note that it does not contain the other changes):
Cleanup · WarmUpTill/SceneSwitcher@391cc20
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
github.com
If you are referring to the scene item selection then that source type should in theory be picked up automatically as I am using obs_enum_source_types to populate that list.
Destroy666
Member
I noticed that the "if recording stopped" and "if streaming stopped" conditions ticket to happen only on condition change fire at start of OBS. Is this a bug or am I missing something? I'll report it on GH if needed.
OnlyZips
New Member
Thanks now working fine...Ah sorry about that - I was too focused on the macro list that I did not even notice that the conditions / actions section was not updated.
A build with a fix should be available here in a few minutes:
Export import · WarmUpTill/SceneSwitcher@24b3c20
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
Warmuptill
Active Member
I am not sure I understand what the issue is exactly.
Can you share the macro settings that are causing issues?
Just in case you still want to have look, I cleaned up the last build and fixed some issues.
A new will be available here in a few minutes.
Scene item index · WarmUpTill/SceneSwitcher@b621771
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
github.com
Destroy666
Member
The condition is simply "if recording stopped" or "if streaming stopped", nothing else. The "Perform actions only on condition change" checkbox is ticked. Advanced Scene Switcher is configured to start running with OBS. I open OBS and both conditions are met, even though the recording/streaming has already been stopped as the application wasn't running.
Warmuptill
Active Member
So something like this does not work for you?
Sorry if I am missing something obvious.
Destroy666
Member
It does work. What I'm saying is it works too much and it shouldn't trigger at OBS launch because I'm not willingly stopping recording/streaming then. And only of one of the conditions is needed to reproduce, e.g. just "streaming stopped".
Warmuptill
Active Member
Ah, I see now what you mean.
But I don't think adjusting the logic of these condition types makes sense here.
Instead I would suggestion to adjust your macro setup to cover that case.
For example, automatically pause the macros checking for the streaming / recording state on OBS startup and only unpause them after you have started streaming / recording at least once.
Let me know if you need further details how to set this up.
Destroy666
Member
Hmmm. I think "perform only on condition change" checkbox is inaccurate in this case, as e.g. recording wasn't playing to be stopped, so did the condition in fact change? It's a matter of interpretation of the word "stopped" I guess, but IMO it's more intuitive when a state change is exact, as specified.
But if you think otherwise, what about a "don't check for conditions on startup" kind of checkbox instead? Setting up let's say 10 macros (as I assume other conditions may have similar issue) like that just to avoid one execution is not great, TBH. It's 3 additional macros to manage just for streaming/recording, if it was 10 different ones then most of my current macros list would be filled with just workarounds for unintended launch actions.
But if you think otherwise, what about a "don't check for conditions on startup" kind of checkbox instead? Setting up let's say 10 macros (as I assume other conditions may have similar issue) like that just to avoid one execution is not great, TBH. It's 3 additional macros to manage just for streaming/recording, if it was 10 different ones then most of my current macros list would be filled with just workarounds for unintended launch actions.
Yeah, I think it *is* interpretation. I think of "stopped" as a static "not running", so it can in fact be true for more than one scan or even continuously. Then add a "one-shot" that starts with an assumed previous state of "false", and now it sees "true" on the first scan, so it runs.
I think "don't check on startup" should be specific to each macro. Or maybe a global setting by default, with each macro able to override the global for itself. The reasoning is to keep the "one-shot on startup" working, so it can clean up whatever might have been left weird from the previous session. That macro has an always-true condition (plugin running), with the "only on change" one-shot.
Or, a new condition of "Startup", that is always true on the first scan and never again, could solve both:
- The set up simply uses "IF Startup" directly.
- Any unwanted one-shots on startup could add "AND NOT Startup" at the end...maybe. It depends on how the one-shot actually works: tacked on once at the end, or applied to all expressions before they're combined.
Last edited:
Warmuptill
Active Member
The default state a macro is in is that its condition evaluate to "false".
So from the plugin's perspective the condition changed from "false" to "true" on OBS startup in your specific scenario.
Thus the actions of the macros are executed with the "on change" option enabled.
My main concern with your proposal is that this might brake a lot of existing setups.
Because now every macro, which has the "on change" option enabled, must first evaluate to false (excluding the default state), before it can ever be executed. (Please correct me if my understanding is wrong)
So for example, a simple macro like "on any day after 6pm (on change) start recording" will no longer work if you start OBS after 6pm.
However, I am of course not against adding another option / functionality to simplify your setup.
Would the suggestion by @AaronD work for you? (Just not yet sure how to best describe that option in the UI)
If not, can you maybe describe the specific use case in more detail?
Destroy666
Member
"if not startup" could work much better as well, new macros wouldn't have to be created, at least. Just one more condition per existing macro, which is much cleaner.
I'd rather have the Or... option that I added later:
But even better still - and would certainly break *everyone's* rig, so it probably won't happen - would be to have a Ladder Logic editor like most industrial controls platforms have, or at least something that covers all of the same functionality.
Ladder Logic started as a literal, physical relay schematic, with electrical power split into two rails, and each "rung" on the "ladder" is its own independent circuit, with switches and relay contacts on the left and relay coils on the right. Each coil controls its own set of contacts, and from that you can build pretty much any logic you want. When you walk into a plant that still uses this old control method and open the cabinet, it sounds like popcorn whenever something happens!
A classic ladder rung, used to control something with a separate button for ON and OFF, that will stay in either state until you push the other button:
Code:
| |
|------NOT [OFF]------+------[ON]------+------(Run)------|
| | | |
| +------[Run]-----+ |
| |Now with software, each relay - really each unique name - has become a bit in a computer, and we're no longer limited to a finite number of contacts per relay. And we can modify the behavior so that it behaves *mostly* like the electrical circuit that it once was, but not quite, in ways that are plumb easy for an interpreter to make sense of.
I especially like the way that Allen-Bradley / Rockwell Automation does it. Each expression starts on the left side with a default of "true", and as you follow an imaginary dot along the line to the right, it gets modified by each block that it encounters:
- When it hits a block, its value is AND'ed with the value of that block. Almost equivalent to a Condition in Adv. SS, and of course each block has both a "straight" version and an "inverse" or NOT version.
- When it hits a branch, the value at that moment is copied to both/all branches.
- When branches combine, their values are OR'ed to continue across the screen.
- When the single, possibly recombined (OR'ed) dot reaches the end, its value is the result of the expression.
- Important for this discussion, a one-shot is simply a block like any other, that can go anywhere, not necessarily at the end and not necessarily in every branch. It could easily be all of the above or any subset. Its value to AND with the incoming value, is simply NOT the previous incoming value.
With the present list of conditions, you kinda have to "just know" that you effectively have all of your open parentheses up front (remember math class?), and you close one with every condition. It's the easiest way to write an interpreter of that kind, and I've done it too, but the existence of others means that a newbie can't know for sure. And it's still ambiguous what the "only on change" one-shot actually does in detail.
Not so with Ladder. The graphical nature makes it obvious what's actually happening...until you start doing something complicated, at which point you probably need to split it anyway.
A-B / RA even allows intermediate output blocks, which would radically change the behavior of a physical circuit, but in their version, it continues to work as above, and simply takes the value at whatever point the output happens to be, and sends it somewhere else while also passing it down the line unchanged. This might not be necessary in Adv. SS (yet?), but I thought it was worth mentioning.
A-B / RA is also interpreted sequentially, not simultaneously, so that an intermediate output on a higher branch (visually) can affect what happens on a lower branch, or towards the right, on the *same* scan, if another block in either of those positions happens to look at the same bit in the computer. This seems like a trivial way for an interpreter to do it, and has some...interesting ramifications for those that want to do something detailed.
---
What I'm thinking for Adv. SS, at least to start with, if it even happens at all, is to have a sequential interpreter that behaves as above, with a single fixed output on the far right side. If this output is true, the macro runs on this scan. If false, it doesn't.
Some essential blocks:
- [Always false], used to disable a branch or the whole thing. Considered bad practice for production (just delete that branch or macro), but useful for troubleshooting. To force something true, just branch around it with nothing in that branch, which is also considered bad practice for production, but useful for troubleshooting.
- [One-shot], as above. Its own value to AND with the incoming value, is NOT the previous incoming value.
- [This macro running], used to prevent parallel copies of the same macro, usually while it runs a Wait action.
- [Startup], true on the first scan, and never again. The existence of this one might affect the decision of which default value the [One-shot] should have.
Code:
| |
|------[Always false]------[One-shot]------NOT [This macro running]------(Run)--|
| |From the descriptions above, I'm sure you can guess what this default does in a variety of different cases, if you replace any of them with anything...except the (Run) at the end; that's permanent.
Pausing a macro might make its starting value "false", which because it's AND'ed all the way across, never replaced, makes the Run output always false as well. But the conditions still run.
---
And once you've got *that* idea, then we can move the Actions up into the rungs as well, as their own output blocks, and remove the one fixed (Run) block: the rung value is always passed through an Action unchanged, and if it's "true" at that point, the action runs.
The Wait action doesn't really make sense anymore with that structure, but there are always ways to get that functionality back, using Timers.
At this point, Timers become their own Actions or output blocks, not part of any Condition or input, and their state can be read by an input block...
So this:
Code:
Do A
Wait 5
Do B
Wait 3
Do C
Code:
| |
|------+------[Conditions...]------[One-shot]------[Do A]------+------[Timer A, set to 5]------|
| | | |
| +--------------------------------[Timer A Running]------+ |
| |
| |
|------+------[Timer A Done]-------[One-shot]------[Do B]------+------[Timer B, set to 3]------|
| | | |
| +--------------------------------[Timer B Running]------+ |
| |
| |
|---------------------------------------[Timer B Done]-------[One-shot]------[Do C]------------|
| |
Code:
| |
|------+------[Conditions...]------[One-shot]------+------[Timer, set to <enough>]------|
| | | |
| +----------------------[Timer Running]------+ |
| |
| |
|---------------------------------[Timer Value > 0]---------[One-shot]------[Do A]------|
| |
| |
|---------------------------------[Timer Value > 5]---------[One-shot]------[Do B]------|
| |
| |
|---------------------------------[Timer Value > 5+3]-------[One-shot]------[Do C]------|
| |- The Timer is enabled by a true input value, and both disabled and reset by a false input value.
- [Timer Running] is only true when the Timer is enabled but not expired yet.
- [Timer Done] is only true when the Timer is both enabled and expired.
I was referring to media actions and signals, as currently I don't see my custom source in Media conditions