Nevermind. I figured it out. Had my Y axis on my frame inverted so the frame outline looked right, but it wasn't registering my mouse.
Resource icon
- Thread starter Warmuptill
- Start date
Nevermind. I figured it out. Had my Y axis on my frame inverted so the frame outline looked right, but it wasn't registering my mouse.
I might call that a "bounds checking" bug. Especially if the box-drawing function still works with the bounds backwards.
Good to know.
Warmuptill
Active Member
Thanks for sharing the logs!
I assume the problematic macro is named "Wont-Work" and it is likely similar to the "At-Bat_Clip_*-of-inning" macros shared in your settings file.
In the shared logs it can be seen that the macro "Wont-Work" is executed many times.
Code:
Line 60302: 18:56:15.930: [adv-ss] running macro: Wont-Work
Line 60889: 18:56:28.119: [adv-ss] running macro: Wont-Work
Line 62064: 18:56:52.633: [adv-ss] running macro: Wont-Work
Line 62471: 18:57:01.207: [adv-ss] running macro: Wont-Work
Line 63370: 19:05:32.809: [adv-ss] running macro: Wont-Work
Line 63919: 19:05:43.786: [adv-ss] running macro: Wont-Work
Line 64213: 19:05:49.658: [adv-ss] running macro: Wont-WorkSo it is not a matter of the conditions not working as expected.
Looking at the actions that are being performed everything seems to be performed as expected from the plugin's point of view and even OBS reports the virtual camera being started and stopped accordingly.
Code:
19:05:43.786: [adv-ss] running macro: Wont-Work
19:05:43.786: [adv-ss] performed action "AdvSceneSwitcher.action.virtualCamera.type.stop"
19:05:43.786: [adv-ss] performed action wait
19:05:43.786: [adv-ss] perform action wait with duration of 1.000000
19:05:43.788: Virtual output stopping
19:05:43.796: Output 'virtualcam_output': stopping
19:05:43.796: Output 'virtualcam_output': Total frames output: 298
19:05:43.796: Output 'virtualcam_output': Total drawn frames: 300
19:05:43.797: Virtual output stopped
19:05:43.802: ==== Virtual Camera Stop ===========================================
19:05:43.830: [ffmpeg muxer: 'Source Record'] Output of file 'C:/InPlayProductions/OUTPUT/at-bat_Game_2023-03-02 19-05-33.ts' stopped
19:05:43.830: Output 'Source Record': stopping
19:05:43.830: Output 'Source Record': Total frames output: 267
19:05:43.830: Output 'Source Record': Total drawn frames: 300
19:05:43.849: warning: 2 frames left in the queue on closing
19:05:44.787: [adv-ss] run "C:/InPlayProductions/OUTPUT/Rename-At-Bat.bat"
19:05:44.791: [adv-ss] performed action "AdvSceneSwitcher.action.virtualCamera.type.start"
19:05:44.792: [adv-ss] detected busy loop - refusing to sleep less than 1ms
19:05:44.792: [adv-ss] try to sleep for 50
19:05:44.792: NV12 texture support enabled
19:05:44.792: P010 texture support not available
19:05:44.796: Virtual output started
19:05:44.796: ==== Virtual Camera Start ==========================================
...So I think the issue might be with the Virtual Camera itself not functioning as expected.
Unfortunately I am not sure how to investigate this further.
Maybe it is simply a timing issue and the virtual camera needs more time between starting and stopping.
So maybe increasing the delay might resolve the problem.
Last edited:
Warmuptill
Active Member
Yes that should be possible by simply using multiple media actions and specifying the different sources, which I assume is what you already tried.
In general the Media macro actions always perform their actions on a global source and not an individual scene item.
Meaning if you restart a Media Source on one scene it will be restarted on all scenes.
I could imagine that maybe the settings of some of your media sources are causing the observed issues instead.
For example you could have accidentally configured a media source to restart each time it becomes active leading to the effect that the media sources were not restarted at the same time.
Similar settings exist for the VLC source also.
Can you double check if that is maybe causing the problem?
P.S. sorry about the very delayed reply - I didn't have internet access for the last week.
Last edited:
So I created the won't work as a test case and it actually worked, not all of the time but some of the time. Almost all of the time the rename-at-bat did not work. You can see that the plugin sees the condition (it blinks) but does nothing. If I hit run it does everything it is told to do every time. Not sayinf there might be something with the virtual camera but if that were the case why does it always work if I manually run the macro by pushing the run button?
Will play with the delays to see if that helps but I already tried that to some degree with no luck
Thanks for all the help
here is another log file. No test case in this one. sceen switch triggered 3-4 times and the only action on the Virtual camera was when I pushed the button to start it
This log file contains just a forced running of the Macro (pushed the run button)
There are 2 virtual camera starts. 1 when I start it after starting OBS and the second when the macro is run to stop and start it.
Not sure if this helps at all but something does not add up to me as to why it runs when commanded but not when the IF condition is meet.
There are 2 virtual camera starts. 1 when I start it after starting OBS and the second when the macro is run to stop and start it.
Not sure if this helps at all but something does not add up to me as to why it runs when commanded but not when the IF condition is meet.
Warmuptill
Active Member
Can you please check if the issue is resolved after setting the following value on the General tab to "0"?
Not sure how it happened but the value somehow was set to 13 seconds.
set to zero everything seems to work again.
I knew it was probably something simple because it was working then quit.
This is by far the most useful plugin for OBS.
Thanks for the help. I feal silly it was that simple because I never touched that number that I remember but makes since how it was screwing everything up.
Thanks agin
Kirk
I can see some cases where that would be useful, but far more useful and less error-prone, I think, would be to remove it from there and make it a macro action instead. Something like "prevent further actions for X seconds", where X could be different each time, and the macro that executes it is immune until it finishes.
Or at the very least, move it to the Macro tab. Not because it's part of a macro, but because the mindset is clearly (to me at least) Administration and Automation, respectively, for the General and Macro tabs, and this feels like an Automation function to me.
Last edited:
CommonsNat
New Member
It seems that having a gamepad plugged in causes constant input detection for the idle event? I've tested with a PS4 and PS5 controller, but both keep the idle event from triggering while plugged in. I'm wondering if it has to do with the gyroscopic input.
CommonsNat
New Member
Okay, turns out this happens when using controller emulation, at least with DSX. Not sure about other controller emulators like DS4Windows.
Howdy folks!
I need help understanding some functionality in order to figure out why something isn't happening. So I have a macro that is set to start at a certain time, let's say 15:45 for example. With the macro enabled and ASS set to 'active', the macro doesn't run. In the logs I see the following:
If I then change the time of the macro's start time to a minute or two in the future, it runs as normal. I can fix this by changing the 'Match behavior' setting 'skip performing actions for' to 0 second, but I'm wondering why I need to change this setting. There are no actions being performed that should trigger the cooldown, unless having a paused macro ('Mar 4th 2', as above) counts for some reasons as an action.
Could somebody tell me why the macro isn't triggering when it's programmed to do so? What counts as an 'action' that is triggering the cooldown?
I need help understanding some functionality in order to figure out why something isn't happening. So I have a macro that is set to start at a certain time, let's say 15:45 for example. With the macro enabled and ASS set to 'active', the macro doesn't run. In the logs I see the following:
15:45:00.080: [adv-ss] condition date returned 1
15:45:00.080: [adv-ss] Macro Backup returned 1
15:45:00.080: [adv-ss] Macro Mar 4th 2 is paused
15:45:00.080: [adv-ss] cooldown active - ignoring matchIf I then change the time of the macro's start time to a minute or two in the future, it runs as normal. I can fix this by changing the 'Match behavior' setting 'skip performing actions for' to 0 second, but I'm wondering why I need to change this setting. There are no actions being performed that should trigger the cooldown, unless having a paused macro ('Mar 4th 2', as above) counts for some reasons as an action.
Could somebody tell me why the macro isn't triggering when it's programmed to do so? What counts as an 'action' that is triggering the cooldown?
So the following appear to work so wondering if this will be reliable or only work part of the time.
So I want to have a macro execute when a source (in a certain area) matches a pattern for more than say 15 seconds and then changes
so I have the following
if - video - source(xxx) - matches pattern (xxx.png) - for at last (15.00 seconds) [perform check only in area]
and - video - source(xxx) - has changed [perform check only in area]
do - xxxx xxxx xxxx etc.
it appears to work but is it really how it should work or just luck and might not work all of the time?
or is there a way to do what I want?
So I want to have a macro execute when a source (in a certain area) matches a pattern for more than say 15 seconds and then changes
so I have the following
if - video - source(xxx) - matches pattern (xxx.png) - for at last (15.00 seconds) [perform check only in area]
and - video - source(xxx) - has changed [perform check only in area]
do - xxxx xxxx xxxx etc.
it appears to work but is it really how it should work or just luck and might not work all of the time?
or is there a way to do what I want?
BishopGreer
New Member
That's the Automatic Scene Switcher, not Advanced. Similar name, vastly different level of capability.
Feature request: Subroutines
Long story short, I (finally!) got my church rig updated to where it'll run the current version of Adv. SS - it was hardware-stuck until now, on Lubuntu 20.04 and corresponding versions of OBS and Adv. SS - and so I'm working on the automation again.
This rig has a finished live feed from the FOH console, controlled remotely by the Broadcast Engineer, but it inherits the FOH mutes and live tweaks, plus a pre-recorded Welcome video that OBS plays itself. For the Welcome video, and at the end of the service, I want to fade down the live feed automatically, so that the FOH Engineer doesn't have to consider the Broadcast as much. I couldn't do that with OBS 25 and that version of Adv. SS, but now I can!
The catch though, is that I actually have 3 sources in OBS, as copies of the same input: Stereo to Broadcast, Mono to Headphones, and Stereo to Headphones. That's so a pair of hotkeys can switch the Headphones between mono and stereo without affecting the Broadcast, because most viewers have their speakers too close together to produce meaningful stereo, but some have headphones. To keep a decent rendition of what they hear, I need to fade all three together, always.
I can do that, by always using 3 actions like this:
but it would be a lot more convenient and maintainable to condense those three that are always together, into a single action. (What's actually shown here, is the same concept for a Noise Gate, to handle the analog cable noise when it's supposed to be silent, but sometimes I want to keep that noise because cutting in and out is even more distracting than having it constant.)
I've tried the trick where a macro has its condition to always run as fast as it can forever, but pauses itself at the end, and then another macro unpauses it. That technically works - turns it into a one-shot on demand - but the "subroutine" actually runs *after* the main macro finishes, when I really want the main one to wait in-place for the sub to finish. If they run in parallel, that's fine too; I'll just put a Wait action in the calling macro.
I've also tried setting a variable instead, so that the "subroutine" macro waits for that variable, does its thing, and then clears it. Same thing: the main macro finishes, and *then* the subroutine runs.
I tried setting the subroutines to "run in parallel", but that didn't change anything. I didn't think to try *everything* running in parallel. Would that make it run immediately? What other problems would it cause? I get the impression that that feature is supposed to be used sparingly.
If it does work, without causing other problems, it would be an okay workaround, but I'd really like to see a proper call / return structure. Arguments and return values would be awesome as well, but the present system of a bunch of global variables technically covers their basic use already. (now watch someone try to compute Ackermann's function on it!)
Continuing the concept of "function arguments", it would also be nice to have the volume level and fade time accept variables, so I could have just one "subroutine" for each concept - Volume, Gate, etc. - that takes the specifics as arguments - Level and Time, {En|Dis}able, etc. And since everyone else who wants to use arguments like that, will have a different action to do it on, you'd probably have to have *everything* take variables in addition to their constants. I hope that's not too much of a paradigm shift.
(This is really becoming a programming language, isn't it? You sure you don't want to just pawn it off to a Python interpreter? Make an API for everything that a plugin might possibly connect to, and the rest is standard Python, at an "add your code here" sort of level that "just works" when you don't mess with the rest of it. Maybe have a menu system, similar to what the macros have now, that insert the corresponding API calls.)
Long story short, I (finally!) got my church rig updated to where it'll run the current version of Adv. SS - it was hardware-stuck until now, on Lubuntu 20.04 and corresponding versions of OBS and Adv. SS - and so I'm working on the automation again.
This rig has a finished live feed from the FOH console, controlled remotely by the Broadcast Engineer, but it inherits the FOH mutes and live tweaks, plus a pre-recorded Welcome video that OBS plays itself. For the Welcome video, and at the end of the service, I want to fade down the live feed automatically, so that the FOH Engineer doesn't have to consider the Broadcast as much. I couldn't do that with OBS 25 and that version of Adv. SS, but now I can!
The catch though, is that I actually have 3 sources in OBS, as copies of the same input: Stereo to Broadcast, Mono to Headphones, and Stereo to Headphones. That's so a pair of hotkeys can switch the Headphones between mono and stereo without affecting the Broadcast, because most viewers have their speakers too close together to produce meaningful stereo, but some have headphones. To keep a decent rendition of what they hear, I need to fade all three together, always.
I can do that, by always using 3 actions like this:
but it would be a lot more convenient and maintainable to condense those three that are always together, into a single action. (What's actually shown here, is the same concept for a Noise Gate, to handle the analog cable noise when it's supposed to be silent, but sometimes I want to keep that noise because cutting in and out is even more distracting than having it constant.)
I've tried the trick where a macro has its condition to always run as fast as it can forever, but pauses itself at the end, and then another macro unpauses it. That technically works - turns it into a one-shot on demand - but the "subroutine" actually runs *after* the main macro finishes, when I really want the main one to wait in-place for the sub to finish. If they run in parallel, that's fine too; I'll just put a Wait action in the calling macro.
I've also tried setting a variable instead, so that the "subroutine" macro waits for that variable, does its thing, and then clears it. Same thing: the main macro finishes, and *then* the subroutine runs.
I tried setting the subroutines to "run in parallel", but that didn't change anything. I didn't think to try *everything* running in parallel. Would that make it run immediately? What other problems would it cause? I get the impression that that feature is supposed to be used sparingly.
If it does work, without causing other problems, it would be an okay workaround, but I'd really like to see a proper call / return structure. Arguments and return values would be awesome as well, but the present system of a bunch of global variables technically covers their basic use already. (now watch someone try to compute Ackermann's function on it!)
Continuing the concept of "function arguments", it would also be nice to have the volume level and fade time accept variables, so I could have just one "subroutine" for each concept - Volume, Gate, etc. - that takes the specifics as arguments - Level and Time, {En|Dis}able, etc. And since everyone else who wants to use arguments like that, will have a different action to do it on, you'd probably have to have *everything* take variables in addition to their constants. I hope that's not too much of a paradigm shift.
(This is really becoming a programming language, isn't it? You sure you don't want to just pawn it off to a Python interpreter? Make an API for everything that a plugin might possibly connect to, and the rest is standard Python, at an "add your code here" sort of level that "just works" when you don't mess with the rest of it. Maybe have a menu system, similar to what the macros have now, that insert the corresponding API calls.)
Last edited: