I have a rig that does exactly that, on Ubuntu Studio Linux. So some things might be different for you.
ubuntustudio.org
I have two simultaneous instances of OBS: one to produce the feed to the remote participants, and one to produce and record the display to the local room. I've called the remote one Master and the local one Slave, because the automation makes it work that way.
Both instances have different Profiles and different Scene Collections so that they don't run over each other, and those are specified on the command-line:
obs --multi --profile "Master" --collection "Master" --startvirtualcam
obs --multi --profile "Slave" --collection "Slave"
obs --help on the command-line to see all that you can do there. :-)
Actually, those commands are in a script that does all of the setup, waits for me to tell it I'm done, and then tears down to leave the system the same as it was to start with. So now I just "run script, get meeting." The flowchart for that script is attached here.
Both instances also run the Advanced Scene Switcher plugin, which handles all of the ongoing automation:
This plugin will allow you to automate various tasks using "Macros". Macros consist of a list of conditions under which a list of actions will be performed. Examples and guides can be found in the wiki. Feel free to contribute! Currently...
obsproject.com
Its settings are part of the Scene Collection, so by having different Collections already, each instance also has different "programming" in Adv. SS.
---
Adv. SS in the Master decodes a naming convention for the current scene, and sends a WebSocket message to the Slave. Adv. SS in the Slave receives that WebSocket message, and switches to the corresponding scene.
There are 2 possibilities for that scene-switching:
- Camera: Window-Captures the meeting window, full-screen. In my case it's a web browser, but it could just as easily be Zoom, Teams, or whatever else.
- Feature: Takes the Master's VCam, full-screen.
The meeting also takes the Master's VCam as its camera, always.
The local display is simply a full-screen projector from the Slave.
---
Audio is not in OBS at all. The Master sends everything it has to the Monitor, which goes to a loopback, and gets picked up by a DAW. (Digital Audio Workstation: a complete sound studio in one app, and lightyears better than OBS's pile of bandaids) Mics also go directly to the DAW, not OBS. The meeting is fed from the DAW through another loopback, the local speakers are fed directly from the DAW, and the Slave is also fed from the DAW through yet another loopback as its only audio source at all. No further processing in OBS, and it only goes to the recording from there.
And as you might guess by now, the meeting audio return goes to yet another loopback and gets picked up by the DAW as its own channel strip.
To automate the DAW, the Master Adv. SS looks at a different part of the scenes' naming convention, and sends the appropriate OSC (Open Sound Control) message to it:
- Mics on/off
- Playback on/off
In the DAW, those OSC messages don't control the flow of audio directly, but rather the amount of a sinewave generator that is sent to the side-chain of a gate. Normally, a gate cuts off or mutes something when it gets quiet, but the side-chain makes it respond to a different signal than what it's processing. So by controlling the amount of the sine generator that goes to the side-chain, I effectively make it mute or unmute the signal that it's actually inserted on.
The reason to add that extra step, is to convert the hard on/off signal that comes via OSC, into a nice fade according to each gate's timing controls.
And because the room mics are far enough away from the room speakers that the standard echo canceller can't account for it, I also have the remote audio return connected to the side-chain of an aggressive compressor for the room mic mix. Because of that side-chain, the compressor doesn't care about the room mics that it's processing, but when a remote person starts talking, it practically cuts off the local mics to eliminate that echo.
This means that the remote people MUST all be muted unless they're actually talking at that moment! And the local people can't talk over them. Well, locally they can, but the remote people won't know it.
The audio flowchart is also attached here.
---
Thus, I have a hybrid meeting that "just works". Run script, get meeting. Name the Master's scenes according to that convention, then produce the feed to the remote people as if it were any other live broadcast, and everything else follows automatically.
As a convenience function, I used one of the newer features of Adv. SS to add a docked button in the Master to start and stop the recording. That button sends a WebSocket message to the Slave, which does that and puts a popup message in the system tray, just for some operator feedback that the message got there.
More screenshots coming, once I move my laptop ("mobile workstation") from my "office" dock to the media dock so that the script and OBS work like they're supposed to...
And here they are:
OBS Master:
The "End of Media" macro is intended to create a nice transition back to whichever camera was previously active. It can be abused, however, by transitioning from one media scene to another. In that case, it would create a loop of those two scenes. So you need to be a little bit careful, and think through the logic that you're programming and then using.
OBS Slave:
The above is two views of the same scene. Normally, the Window Capture completely covers the placeholder text, but when the meeting window isn't present or it's configured wrong, that source is transparent and so the text appears.
