Warmuptill
Active Member
Yes, the scene switcher would check the timing after the condition became true.
It can only be ever as accurate as the interval.
- Thread starter Warmuptill
- Start date
It can only be ever as accurate as the interval.
oh, okay, that clears up things now, thank you!
not sure about the dock panel, but you can set a hotkey to start/stop the plugin in OBS Settings > Hotkeys.
Warmuptill
Active Member
Thanks for pointing that out.
A build where this spam is disabled can be found here in a few minutes:
Fix crash when reordering macros · WarmUpTill/SceneSwitcher@3be4b3f
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
github.com
Thanks, looks good to me.Thanks for pointing that out.
A build where this spam is disabled can be found here in a few minutes:
Fix crash when reordering macros · WarmUpTill/SceneSwitcher@3be4b3f
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
Here's another suggestion I keep forgetting to say here. How about you add a checkbox on "Switch scene" macro actions to "wait until transition is finished"? Currently, we would have to add a wait action after for the timing of the next action, but if we end up changing the transition duration, we would have to adjust the values again. Also, such checkbox could also lead to less macro actions.
Oh, dear, I got another case of the "wrong macro action index". I'm clicking the add button on one of my macro actions, but the copy goes to a different position instead of right next to it. I can't give reproduction steps atm as it would take a while to test around haha. Got it on 1.16.5.
Last edited:
Warmuptill
Active Member
Good idea - i will look into it!
Hm, strange - let me know if you find any way to reproduce it.
uhhh, so basically "for exactly X seconds" will almost never be true?
Warmuptill, AaronD, and dear readers, thank you for your interest/input.
Here is some background and the reasons why this is all like it is.
We need to stream and save the (daytime only) footage of an IP camera to YouTube.
Camera is wired to PC running OBS and stream is constant and without any hickups.
However, the wireless link from PC to the internet sometimes fails (it is a remote location).
It's not only the link itself, there are also often power outages.
So we depend on the Enable Auto-start feature to prevent YT from stopping the broadcast prematurely after the first outage of the day.
Enable Auto-start is only available when Schedule for later is selected.
Because of Enable Auto-start YT doesn't really know when the broadcast should be actually finished.
It keeps waiting for the next portion of the stream until End Broadcast tells YT when to end the whole broadcast.
Regarding date, the goal is to automate the daily streams fully, so that every day a new stream is started and stopped at certain times.
Every day a new name needs to be generated and registered with YT like
"yyyy/mm/dd-Ascraeus Mons stream"
where "-Ascraeus Mons stream" doesn't change.
Right now we have to manually
remotely connect to that location,
click End Broadcast in OBS,
wait a few minutes so YT can do it's work wrapping up the stream,
click Manage Broadcast,
click Create New Broadcast,
select Schedule for later
deselect Enable Auto-stop then
enter the date for the next day,
enter the time the stream should start,
click Schedule and select broadcast.
Disconnect from that location.
Advanced Scene Switcher each day then starts and stops the actual stream, and that is a very great time saver indeed, since that must be triggered at certain times.
I don't know if there is an API for End Broadcast, but it would be great to have that.
Also don't know about metadata?
I guess a new broadcast can be scheduled with Advanced Scene Switcher, but haven't tired that yet.
And the date+1 thing would also be really great!!
Thanks guys and sorry for late reply, had to take care of mom.
Wish you a Merry Holidays.
Here is some background and the reasons why this is all like it is.
We need to stream and save the (daytime only) footage of an IP camera to YouTube.
Camera is wired to PC running OBS and stream is constant and without any hickups.
However, the wireless link from PC to the internet sometimes fails (it is a remote location).
It's not only the link itself, there are also often power outages.
So we depend on the Enable Auto-start feature to prevent YT from stopping the broadcast prematurely after the first outage of the day.
Enable Auto-start is only available when Schedule for later is selected.
Because of Enable Auto-start YT doesn't really know when the broadcast should be actually finished.
It keeps waiting for the next portion of the stream until End Broadcast tells YT when to end the whole broadcast.
Regarding date, the goal is to automate the daily streams fully, so that every day a new stream is started and stopped at certain times.
Every day a new name needs to be generated and registered with YT like
"yyyy/mm/dd-Ascraeus Mons stream"
where "-Ascraeus Mons stream" doesn't change.
Right now we have to manually
remotely connect to that location,
click End Broadcast in OBS,
wait a few minutes so YT can do it's work wrapping up the stream,
click Manage Broadcast,
click Create New Broadcast,
select Schedule for later
deselect Enable Auto-stop then
enter the date for the next day,
enter the time the stream should start,
click Schedule and select broadcast.
Disconnect from that location.
Advanced Scene Switcher each day then starts and stops the actual stream, and that is a very great time saver indeed, since that must be triggered at certain times.
I don't know if there is an API for End Broadcast, but it would be great to have that.
Also don't know about metadata?
I guess a new broadcast can be scheduled with Advanced Scene Switcher, but haven't tired that yet.
And the date+1 thing would also be really great!!
Thanks guys and sorry for late reply, had to take care of mom.
Wish you a Merry Holidays.
Warmuptill
Active Member
Well it will only ever be as accurate as the interval configured on the general tab.
The main difference between "for exactly ..." and "for at least" / "for at most" is that it will only match at the moment the time was reached and not after / before it.
I chose to use the wording "for exactly" to differentiate it from the "at least" / "at most" cases but it might not be the most clear.
If you have a suggestion for a better name I am all ears :)
Warmuptill
Active Member
I now implemented a first version of this functionality.
A build with this change can be found here in a few minutes:
Add option to wait for transition to complete · WarmUpTill/SceneSwitcher@fbd4c7c
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 works as expected! :)
The way I would do it in industrial controls is to build the "for at least" logic (I had to build that every time, from the immediate logic plus a timer; it wasn't inherent), and then put a "one shot" after that. The "one shot" is true for exactly one scan when its input becomes true, and then false afterwards. Maybe that can help to explain this one, and possibly with the name too???
Like all DSP functions (Digital Signal Processing), this is entirely based on the scan time or sample rate, and cares nothing about actual time. (so if you change the sample rate, all of the time-based functions need to be updated for what the system thinks is a different time*)
Thus, the concept of "exact time" does indeed work, as it's really a translation into discrete samples, one of which *will* be an exact match because the translation makes it so. (it just might be off a bit in absolute time)
---
* Thankfully, Warmuptill has made all of that math transparent to the user, and if I'm reading between the lines correctly, they've even made multiple clock domains between a fixed fast one and a slow user-defined one. Some of the logic happens in the fast world, and some in the slow world. It might not be obvious from the code, but this is still more-or-less what it's doing.
lindenkron
Member
Thanks!
I think I found the problem.
A build with a fix should be available here in a few minutes:
It would be great if you could quickly confirm whether or not the problem is resolved on your end as well.Fix crash when reordering macros · WarmUpTill/SceneSwitcher@d18d596
An automated scene switcher for OBS Studio. Contribute to WarmUpTill/SceneSwitcher development by creating an account on GitHub.
I also added the option to check whether or not studio mode is currently active to this build.
View attachment 78121
Just to clarify - are you referring the media condition type in the Macro tab or the separate tab labeled "Media"?
In case of the latter this would actually be "expected behaviour" as the the way the priority system works is that checks are only performed until one functionality fulfils its conditions and a match is found.
So if the macro tab functionality is running in a continuous loop and thus a match is always found the other functionality like the media tab will not get a chance to run.
The easiest way to solve this would be to just transition your entries from the Media tab to the Macro tab so you can rely on the "run in parallel option".
But you are not the only user who stumbled upon this issue, so maybe I should adjust things.
The reason it was implemented in this way is that if a user configured automated scene switches via the macro tab and also the "old" tabs two scene switches could clash with one another and result rapidly flickering scene changes.
But maybe I can find a way to work around this.
It appears to have done the trick! At least I can move them up and down, and OBS does not crash! :)
Sorry about the slow reply, holidays and all.
Happy Newyears & Holidays!
lindenkron
Member
Hey @Warmuptill
Is there anything you can do about duplication sources not showing up in the dropdown menu for stuff such as Scene Item Visibility? I've had this issues other places as well. Not sure if it's possible in the environment you're working in, but I know Stream Deck managed to implement the capabilities of selecting specific duplicated sources.
Example above. Only one is visible in the dropdown; but there's 4 sources.
Thanks!
-Lind
Is there anything you can do about duplication sources not showing up in the dropdown menu for stuff such as Scene Item Visibility? I've had this issues other places as well. Not sure if it's possible in the environment you're working in, but I know Stream Deck managed to implement the capabilities of selecting specific duplicated sources.
Example above. Only one is visible in the dropdown; but there's 4 sources.
Thanks!
-Lind
You can rename them, independently of what they are. Is that too much trouble? (if you're adding and removing constantly, then the answer could very well be yes)
If they do need to have the same name, then how do you tell the difference in the dropdown? Looks like they're in alphabetical order, not the user's order from the Sources list, which would destroy any confidence that I might have had in choosing the correct identical name.
It is actually a very common use case to duplicate sources and keep their names the same. Sources with the same name mean that they are references to only one source. If they are separate sources, then it will take more OBS resources. This is especially true when you use window captures, and you're using the same source in a scene with different layouts. If you use two separate window captures, then OBS will likely use 2x the computing power for capturing the same window (not that I know internals, but this is a rough estimation of the difference).
I'd argue that I actually expect to see the scenes and sources in the order in which they appear in the UI. When you have many scenes, you would place the related ones near each other. Seeing them in alphabetical order makes it harder. In addition, when you see them in the order you see them in the Sources panel, you get the sense of layers, and you would be able to find which one is on top.
Warmuptill
Active Member
Thanks for the suggestion regarding duplicate source names.
I will look into whether or not this is feasible.
@lindenkron you mentioned that other tools faced the same issue.
How did they solve the issue of displaying the same entry multiple times on the UI side?
I can of course just add the same name X amount of times but that would probably be a bit confusing.
I will look into whether or not this is feasible.
@lindenkron you mentioned that other tools faced the same issue.
How did they solve the issue of displaying the same entry multiple times on the UI side?
I can of course just add the same name X amount of times but that would probably be a bit confusing.
Last edited:
lindenkron
Member
Hey @Warmuptill
The representation was very simple. Same identical name; but they're placed in the same order as you see it in your scene items. So 1 in the list, is 1 in the 'scene.item' list.
Now how they did it technically, I can't say. Here's the Stream Deck repo: https://github.com/elgatosf/streamdeck-obs-plugin
Here's a visual representation of it.