macharborguy
Member
Let me just say that I really like the development of OBS MP thus far...
However (there it is)...
It is very difficult for me to make the jump to it for a number of reasons.
I am still using original OBS, and an older version of the CLR Browser Source, as well as OBS Remote, all three of which are no longer maintained, but all three combined give me the most power for creating effects and features on my streams. OBSRemote gives me the ability to not only change scenes without hotkeys, but also gives me a web-socket interface with OBS so the on-screen widgets can be aware of the current scene and adjust themselves accordingly (like a global source chat widget that adjusts its size depending on the scene that is being displayed, or a global follower widget that mutes itself when it is not in the current scene, bypassing the need to reload the source on scene change).
THe reason I am using an older version of CLR Browser Source is due to performance. I use Foobar 2000 to display track information, and have a very visual on screen music widget that displays different meta data for the song, as well as the album art, all via AJAX with JQuery, and on top of that I have animated gifs that have their speed near-perfeclty adjusted to "dance" to the BPM of the song playing. In order for this to work, i need to constantly poll the Foobar file for changes (i have the foobar file output as a JSON format so i can parse all the data easilly). The current version of CLRBS, for some reason, outputs EVERY AJAX file request to the log file, and since i do the requests at such a short interval, within 30 minutes the file it topping 2Megs. Not a huge file, but the amount of logs being output just drags performance of the sources down overall. In addition, the overall performance of the current plugin pales in comparison to the previous version that I continue to run.
I have looked at Game Show and XSplit, and neither of their methods of HTML sources are as feature rich as the CLR plugin I continue to use. In addition, neither support WebSocket style interfaces that I can make use of.
The worst part is that Open Broadcaster has begun crashing on me during casts, seemingly out of nowhere, due to the browser source plugin, which is odd since i had not changed anything about my configuration since mid December.
My only options are either to drop the features that I have used on my streams over the past 2 years and move to OBSMP, or stick with the software I am using now and just live with the crashes each cast.
TL;DR
Please consider implementing a WebSocket API, much like the now-possibly-defunct OBSRemote, into OpenBroadcaster allowing end users to have some remote control interfaces with the software, as well as gather internal data about scenes, sources, and broadcast information. Automated manipulation of source positioning is not a requirement, though it could prove to be an amazing feature if it was added, but i am not holding my breath on that one.
Scene list, current scene, change scene, source list, show/hide source, mixer list, mute control per audio source, volume control per audio source, start and stop broadcast, start and stop recording were the main features in Remote that I made heavy use of during many of our Guns of Icarus broadcasts a year ago, and I continue to exploit those features any chance i can in my JavaScript/BrowserSource projects.
Thank you for the great application!
Rob of The Rob And Dan Show - http://twitch.tv/TheRobAndDanShow
However (there it is)...
It is very difficult for me to make the jump to it for a number of reasons.
I am still using original OBS, and an older version of the CLR Browser Source, as well as OBS Remote, all three of which are no longer maintained, but all three combined give me the most power for creating effects and features on my streams. OBSRemote gives me the ability to not only change scenes without hotkeys, but also gives me a web-socket interface with OBS so the on-screen widgets can be aware of the current scene and adjust themselves accordingly (like a global source chat widget that adjusts its size depending on the scene that is being displayed, or a global follower widget that mutes itself when it is not in the current scene, bypassing the need to reload the source on scene change).
THe reason I am using an older version of CLR Browser Source is due to performance. I use Foobar 2000 to display track information, and have a very visual on screen music widget that displays different meta data for the song, as well as the album art, all via AJAX with JQuery, and on top of that I have animated gifs that have their speed near-perfeclty adjusted to "dance" to the BPM of the song playing. In order for this to work, i need to constantly poll the Foobar file for changes (i have the foobar file output as a JSON format so i can parse all the data easilly). The current version of CLRBS, for some reason, outputs EVERY AJAX file request to the log file, and since i do the requests at such a short interval, within 30 minutes the file it topping 2Megs. Not a huge file, but the amount of logs being output just drags performance of the sources down overall. In addition, the overall performance of the current plugin pales in comparison to the previous version that I continue to run.
I have looked at Game Show and XSplit, and neither of their methods of HTML sources are as feature rich as the CLR plugin I continue to use. In addition, neither support WebSocket style interfaces that I can make use of.
The worst part is that Open Broadcaster has begun crashing on me during casts, seemingly out of nowhere, due to the browser source plugin, which is odd since i had not changed anything about my configuration since mid December.
My only options are either to drop the features that I have used on my streams over the past 2 years and move to OBSMP, or stick with the software I am using now and just live with the crashes each cast.
TL;DR
Please consider implementing a WebSocket API, much like the now-possibly-defunct OBSRemote, into OpenBroadcaster allowing end users to have some remote control interfaces with the software, as well as gather internal data about scenes, sources, and broadcast information. Automated manipulation of source positioning is not a requirement, though it could prove to be an amazing feature if it was added, but i am not holding my breath on that one.
Scene list, current scene, change scene, source list, show/hide source, mixer list, mute control per audio source, volume control per audio source, start and stop broadcast, start and stop recording were the main features in Remote that I made heavy use of during many of our Guns of Icarus broadcasts a year ago, and I continue to exploit those features any chance i can in my JavaScript/BrowserSource projects.
Thank you for the great application!
Rob of The Rob And Dan Show - http://twitch.tv/TheRobAndDanShow