The obvious route — putting the callers on a bus and sending that bus to Master with the M button — doesn't work for callers: vMix deliberately excludes any bus sent to Master from the callers' return feed (otherwise mix-minus would break), so the callers would stop hearing each other.

The more complex setups I've seen solve it externally — each call out on its own bus to a hardware desk/Dante, build the mix-minus there, feed program-minus back per caller. Works, but it eats buses fast (an out and a mix-minus bus per caller) and assumes you've got the desk.

For a pure in-the-box setup, the only clean idea I can come up with is to leave the callers on Master (so mix-minus stays intact) and drive their faders together via the API — one action firing SetVolume on each caller's GUID at once, or mapping a single controller fader to several caller inputs. In theory that's group control without touching the bus routing. I haven't confirmed whether one physical fader maps cleanly to multiple SetVolume targets at the same time — has anyone done that, and does it hold up live?

For context, here's the rest of the setup I worked through, in case it helps anyone untangle the logic:

You add the input via Add Input → Video Call, and for each caller you use "Host a Call" — you're the host, and each guest connects with the URL and password vMix generates. The nice part is the audio: vMix mixes it automatically so a caller's own voice isn't sent back to them, which is what would otherwise cause feedback. So there's no complicated routing to build — it more or less explains itself once you see it that way.

Next question I ran into: what happens to a caller's audio when they're not on screen? If you switch between different shots, the audio drops out with the picture. The fix: once the call is created, double-click the input, go to the General tab, and uncheck "Automatically mix audio". Now the audio stays on wherever you've enabled it, independent of the picture — and from there you can also send a caller to a separate bus for processing or an external feed, while still bringing their video in as an overlay.

On the display side, one limitation worth knowing: the Layer 1/2/etc. positions don't apply when you bring an input in as an overlay — the overlay uses the input's Main position. So I set the position on the Main of the call input, which means that guest can't also go full screen at the same time. Not a big deal for a commentator who's meant to stay small anyway. For richer layouts I add a background graphic as an input and use Layers to arrange the callers on top — pick a 2- or 4-box preset, drop the guests/host in, and build a few of those as separate scenes. Then you can switch between one guest, two guests, three guests, or cut a single guest in to comment over a video. Between that and the simple overlay you've got pretty much every situation covered.

One thing not to forget: if you send a guest to an additional separate bus for processing, don't route that bus back into Master — same mix-minus trap as above.

So the only open piece for me is the group-leveling question at the top — would love to hear how you handle it.

Thanks for the tip — I see what they're doing. Same idea I'd been circling: the source sits as a layer on a background input, and the layer geometry (move/crop) does the sizing, so the source itself stays full and untouched. Driving the layer positions dynamically over a script is clever, and it's a good route to nicely styled, framed results — though it's pretty involved, and you get a similar result the simpler way without the XML gymnastics. The bit I'd missed: the background doesn't have to be a Background Picture — you can drop the layer straight over a running video/cam, which covers "small source over live footage" without touching Main at all.

Nice channel, by the way — I'll be digging through it.

On audio: buses were my first move too. My understanding from the docs/threads is that the moment you send a caller bus to Master via M, it gets excluded from the callers' mix-minus (so they'd stop hearing each other) rather than just summing into Main — but I haven't been able to test that part end to end yet, so take it with a grain of salt. Happy to be corrected. I'll look at that software-mixer option you mentioned anyway; I've been toying with a background software mixer idea.

For now, what works for me: leave the callers on Master (not summed into a bus, so mix-minus stays intact) and fade their volumes together over the API — a group fade via SetVolume, acting like a group fader without touching the routing.

Rough idea (simple input IDs here just for readability — in practice I key on the GUID, which stays stable across reloads/appends):

callers = [1, 2, 3]
fadeGroup(callers, target=80, ms=400)
# per step, fire SetVolume on each caller:
# GET /api/?Function=SetVolume&Input=1&Value=...
# a small sleep between steps gives the fade

That group-call level approach already works for me in software — right now I'm exploring how the dials could drive it physically.
Curious whether your bus setup gets the same group-ride more simply — no-desk-everything-in-vMix is the goal.

Ah, that makes sense if you're building the callers their own mix on a bus as the return feed — which is exactly what I was trying to avoid. That's the n-1 / aux-send logic from the desk world, done with vMix buses, and it explains why the bus never goes to Master.

Different goals really: you build tailored return mixes, I just ride a caller group on the program with callers on Master and standard mix-minus. The bigger reason I lean that way is that I want to control everything remotely — the more tailored bus routing you add, the more individual points you have to coordinate from afar. Keeping it lean (callers on Master, group level over the API) makes the remote side much simpler, and that's really my goal here. Probably solvable over the API on the bus side too, just more moving parts.

End of the day, both work. Thanks for walking through it.