I'm a huge fan of Vmix and am completely enamored of Multi-View. The problem is, this relationship is sometimes a love/hate affair.

I feel a bit like I'm looking the proverbial "gift horse in the mouth" in offering this point of view and these suggestions on a feature set that delivers so much value for the dollar already. Martin has done an awesome job delivering what we have so far, but IMHO, it could operate more simply and completely. Lets see what my comrades-in-arms here think.

My goal is to mimic the look of cable news network remote panel discussions with up to 8 remote panelists participating through Vmix Call.

One of the great things about merge transitions between multi-views is that it allows the viewer to readily track the participant who is talking among a number of on-screen participants as we dynamically transition to a single participant view or rearrange the on-screen participants to enlarge the one speaking, add or drop out others, etc. There's also a certain joy in watching that transition happen. Here's what it currently takes to do that (with a 1 or 2 pixel border on each image):

- One input for the original source (i.e. a Vmix Call)
- One color input (or looping video) with that call input on top of it (multi-view), slightly zoomed-out, to reveal 1 or 2 pixels - this for a full-frame image with border
- One or more alternately cropped versions of the input above (so, another input for each crop)
- One input for each layout of participants; perhaps some with all 8 and some with fewer and some with alternate sources, like a video of what they're talking about.

With me so far? That's already a lot of inputs - especially as you add more layouts. Now let's add an additional variable, what input we're transitioning from or to (full frame). To look right, the input you're merge transitioning from or to should be at the highest number in the multi-view. That doesn't seem like such a big deal - unless you're trying to build a library of templates so that, without knowing in advance, you can transition to any participant necessary. It seems to me that a common, cohesive multi-view naming strategy is called for, perhaps like:

8A-1T where "8" refers to the number of inputs, "A" is layout version A and "1T" is for input 1 being is on top (the highest multi-view number) - which would allow transitions from or to that input. SO "8A-8T" is the same layout but with the input in multi-view slot 8 is on top and will remain so during a merge transition to that input as full frame or an alternate position. Keeping count? That means, in this case, 7 additional virtual multi-view inputs in order to support possible merge transitions for each input - multiplied by however many multi-view layouts you need - yikes!

The idea of setting these up on-the-fly during a live webcast scares me - especially since they have to be tested live because they transition from "Preview" to "Program." So, we'd instead most likely want to set them all up in advance; which means lots and lots of inputs. I've also learned (thanks, Martin) that how the border colors move (under the on-screen multi-view inputs) during merge transitions is dependent upon whether the inputs were created from scratch or created as virtual copies).

So, what might be done about this? I'm not a developer and don't know if the current architecture will even support this, but...

1. If the ability to create a color or video border (of "x" width & type - like beveled) could be moved to each of the 10 layers in a multi-view; within the bounds of the current frame, it would remove the necessity to create one or more inputs just to support borders - and the border motion during a merge transition would be locked to its corresponding input.

2. Along with #1 above, this would also likely mean that we wouldn't need a separate input for each additional cropped input to support each multi-view layout.

3. There are likely several ways to deal with the need to have a different version of each multi-view layout to support merge transitions to each input within it:

- Add "intelligence" that looks at which input is in preview and automatically put that input (in the multi-view) on top just before the transition begins.

- Create a "Merge-2" transition that manually does what the "intelligence" option above does

- Treat the selection of which layer of a multi-view is on top similar to the way we can select which of several text overlays are used from within a single input; with a right click selection (among input names and numbers used in the multi-view)

4. One of the related issues that I've run into is that after the cropped positions are all created, a camera or laptop moves slightly - putting the participant off-center within the box. If we can't easily move the camera or laptop, it would be great to be able to re-position that participant with controls (and shortcuts) for that input - but only within (or under) his multi-view layer. We can already do this if the input is, for instance, 4K and we're working in a 1080 preset - but only on the input itself.

Looking forward to thoughts from the community. Please add a "+1" if you agree.

Thanks.

-David

multiple multiviews (copies of one another layers rearranged, 96 in total) and merge quickplay settings for those inputs/multiviews, that's ít

- How can you set quickplay as default behaviour when I click to an input?

Input > General > Mouse click action > Quickplay

No, the borders are not always part of the background. Please check at 9:18. The border is already embedded in the vmix call as it zooms out.

And 1:18 we can see that the the border is already present in the input.

If it is already in the input, why when he switches to that input at full screen, the border is not visible?

We are missing something I think...

My guess is that the border is added as a mulilayer to the input, which in turn is zoomed in so that the border is outside of the viewable area.
(at least that's how we do it.)

yes the $200 to buy the set and check it all out ;-)

Please, have a look at this tutorial. It adresses several issues discussed previously:
- Border issues
- Overlapping issues when doing the merge effect