Rank: Advanced Member
Groups: Registered
Joined: 8/21/2019(UTC) Posts: 67 Thanks: 7 times Was thanked: 3 time(s) in 3 post(s)
|
Originally Posted by: spinfold Originally Posted by: Narcogen Originally Posted by: spinfold Originally Posted by: JackMortonAuditorium I leave the bus the remote is listening to the same, and take the other devices on or off that bus.
I also use G as my green room, and A for playback and B for mics, so I take people on or off live by either adding or removing their output from the appropriate bus, or moving the designated bus on or off master, but my remotes, whether they are vMix Call or Zoom, are always listening to G.
I also use G as the green room audio. Let's say we have a presenter in a studio, two vMixCall presenters and a Zoom presenter. I have a Streamdeck button for each (apart from Zoom, so far) which toggles them individually between listening to Output and talking to M, or listening to G and talking to G. This enables the two vMixCallers to speak to each other (on G) while the studio presenter is going to programme. Alternatively, the studio presenter and one of the vMixCallers could speak while the other vMixCaller is presenting. As we are unable to change the audio bus going to Zoom once the meeting is setup, it is impossible for this to happen with Zoom presenters. I could set them up initially listening to G, and could toggle their *speaking* to G or M button, but they would always hear green room and never programme. I could route the programme elements also to G for them, but then the two vMixCallers cannot have an off air conversation because the programme feed would interrupt their off air conversation with each other. I could have a dedicated bus just for Zoom (let's say bus F) but it would work differently to the other selections (would be changing audio channels going into the bus, rather than the audio permanently going into the bus and just changing which bus they hear) and would need two buttons, one to toggle their listen and one their speak. It would work, but it's not very elegant and means the workflow cannot be standardised across all sources. Given that Zoom themselves allow changing of the audio source from a context menu directly in the UI of their app (without even going through a whole settings dialogue) I don't know what the issue would be. I'm guessing the issue is what while it can be done in the app, it is not exposed to the API. Ultimately this is just a personal preference, I guess-- I already prefer to work where I'm dedicated a bus for this use and I take devices on and off it-- I don't necessarily need two button presses, I just need buttons that move multiple devices on and off the relevant bus to toggle talkback, and since I'm already used to working that way with vMixCall, changing to Zoom does not require me to change, so I'm just lucky in that respect. If your workflow depended on changing which source goes to Vmix Call, then that breaks for Zoom because we currently can't do it. I'm speculating that it's not supported in the API because I think if it was they'd have already implemented it, since they do have that functionality for vMix Call. Unless I'm misunderstanding something, it's not personal preference, it's necessary to do what we need to do (I think!) You say you have a dedicated bus - let's say Bus G. To me, that means that you have all (up to) 8 vMixCall callers listening to Bus G all the time, and you then switch in and out which other audio sources (including other vMixCalls) are routed to Bus G. Is that correct? If so, how do you as director/producer speak individually to one vMixCall without the other callers hearing you? The only way I can think of is to switch the bus to that one vMixCall. That's what I'm getting at about Zoom, though. It makes sense for vMix to implement this feature for vMix Call because each call is individual. But no matter how many Zoom inputs you configure, you're only in one meeting; as far as I know, there's no way to talk to just one participant in the meeting, you're always just talking to the meeting, unless you're using the backstage functionality of a webinar, and even then, I think you're speaking to everyone who is backstage. Originally Posted by: spinfold
Another scenario we need is the ability for one vMixCall caller to speak to another vMixCall caller, while a third vMixCall is speaking on air and the other 5 are listening to programme. Again, how is this possible without switching audio source to the various vMixCall inputs?
It's not! But that won't be possible with Zoom even if vMix implements the feature you describe, because AFAIK Zoom doesn't have this functionality at all. That is the backstage functionality in Webinar-- that's how Zoom implements this. But vMix isn't going to be able to make this work the way it can with vMix Calls, because whether you're speaking or appearing onstage or backstage in Zoom is based on where your account is. If you're one-manning a show and appearing in a Zoom webinar via Vmix, you can't be "onstage" providing program video and audio to webinar participants, and simultaneously be "backstage" doing off-air comms with future presenters. I think the presumption that underpins Zoom's design choice in this area is that events are first and foremost Zoom events, and everything else is secondary. A lot of our events are recorded, streamed, but also hybrid-- so the audience just isn't the target of vMix's program audio and video feed, but may be watching live on YouTube *or* spectating via Zoom. So if you're only worried about vMix program audio/video as the audience, you're free to assign whatever outputs you want for each individual vMix Call participant, and route audio to and from a TD or between remotes as you describe, and as long as none of it goes to program, you're fine. But Zoom muxes all the audio in the cloud, so if you're in a meeting, there's no way to send audio to particular participant but not the others, and no way short of using the webinar backstage feature of sending audio that isn't going to the Zoom event's equivalent of "program". I guess this is just a long way of saying that vMix Call was built to be a solution for both remotes coming on to program and to provide comms, whereas Zoom's design presumes it is a first class program output. If Zoom had a way, in the webinar backstage, of routing audio from one client to one or more clients without going onstage OR to the general backstage feed, then it'd be woth vMix implementing input device level changing for a Zoom input, but without that, it's not that missing feature that's stopping it from reaching feature parity with vMixCall, it's that Zoom assumes you have one big room, or at best, one big stage and one big backstage, whereas vMix Calls are isolated by design, and if you want one big backstage, you have to build it that way yourself. I only hope that vMix's choice to implement Zoom the way they have doesn't mean they'll give up on vMix Call.
|