Hello everyone!

First, I'm so happy to join this community around a fantastic software like vMix!
Just a thing, I'm French, so my English is not perfect. I will try to write with a good level, without Google Translate (it's worse when I'm use it...)


For my first message, I have a feature request... and not a simple one! I know... Sorry dev team!


We have, in a radio studio, a vMix system with auto-switch by triggers.
This is so perfect....... but this way makes some problems.


Global delay

First, we don't have a global delay for auto-switching: if 2 people are talking quickly between theim, the program will also switch.... quickly. Very quickly. This makes the spectator... sick :)
Even if I set a trigger delay.

The idea is to have a "Global delay" for auto-switching.

For example, if I have a global delay to 2500 ms, the auto-switching will respect simply at least 2500 ms between two switches.

But not a queued auto-switch, of course.
vMix just ignore any auto-switch during the global delay.


M/E support (the harder one, I think...)

The first idea is attached to this one.

Example:
I have 3 cameras with 3 M/E (multiviews) :

1) Camera 1
2) Camera 2
3) Camera 3
4) M/E 1 (cam 1-2)
5) M/E 2 (cam 1-3)
6) M/E 3 (cam 2-3)
7) M/E 4 (cam 1-2-3)

When camera 2 and 3 are talking in a short time (with a delay configuration), vMix will choose to display my input 6, that contains my camera 2 and 3.

But I know this feature is so hard to integrate for all situations in the vMix interface.
Maybe with a new source type, like audio input, an "audio-switch" source type?
For each sources, we can declare what is the audio-switch source(s) attached.

Example:
1) Camera 1 (linked to 7)
2) Camera 2 (linked to 8)
3) Camera 3 (linked to 9)
4) M/E 1 (linked to 8 AND 9)
5) M/E 2 (linked to 8 AND 10)
6) M/E 3 (linked to 9 AND 10)
7) M/E 4 (linked to 8, 9 AND 10)
8) Audio-switch 1
9) Audio-switch 2
10) Audio-switch 3

If audio-switch 2 are triggered, vMix will switch to input 2...
But if audio-switch 2 AND audio-switch 3 are triggered at the same time, vMix will switch to input 6, that is linked to audio switch 2 and 3. (same example with 1-2, 1-3 or 1-2-3)

We can imagine a delay field in configuration to consider a "multiview situation. (example: if multiple audio-switches are triggered together 3 times in 5000 ms, we can consider we are in "multiview situation")


Detect time

I promise... it's the last one!
Always about audio triggering, just to define a delay for triggering.
For example, if I define for an audio trigger a detect time of 300 ms, vMix will trigger ONLY if the treshold level is triggered during at least 300 ms.

With that, the studio noises like microphone "quick noises" (shock, laughs, 'Ah!', 'Oh!', 'Yes', 'No'...) or applauses will not show the camera!



I'm so sorry, vMix devs... ^^

I hope you think these improvements are goods for you... and maybe soon in vMix? :-)
Thanks


PS : And I hope you have understand my looong message.. I reminder, I'm French :-)

Oh, un français ! :D
(je réponds en anglais, du coup, pour que les autres comprennent !)

Haha, no, nothing is better than a true video director, of course, but, in a radio situation (filmed radio show), mostly in "associative" radios, we don't have a video director in studio, but just a radio host. (we are all volunteers in a lot of associative radios, so we need to adapt the systems)
And the radio host can't switch the video during mixing the radio show. He/she needs to be focused on the main job!

These improvements are mostly for radios.
An automated system can't send text overlays for naming the characters or videos/pictures like a true TV show :-)

In an ideal world, I'm dreaming about clone radio host to have 2 people, but.... I think these improvements are more simple :D


We are using vMix profiles with manual switches to record some video podcasts with a true video director! For interviews, politics, etc.


Thanks for reply!
Benoit.

+1

I have also experimented with doing something like this ... it would be a very useful feature - especially if there is some kind of delay + collision detection that can be implemented in some way, as outlined in the original post. This would add a degree of "intelligence" to the auto-switching.

Audio triggers also need to be allowed to trigger (perhaps optionally), even if a component is in 'program'. To explain this better, I tried to create a multi-view with 2 panels and use an audio trigger to switch the current speaker (from several vmix-calls) into the second overlay. This worked if the multi-view was not in program, but as soon as any component of the multi-view was in program, the triggers (by design) get disabled.

I understand why Martin has implemented the triggers in this way - to avoid trigger-loops, but in this instance, I think there needs to be a way for the operator to over-ride that behaviour (at their own risk!). Maybe some kind of trigger limit could be implemented to stop a run-away trigger?

G.

Our IT guy has this working, he also uses a XML data source from the radio system to
super the current track playing.

At its simplest level it needs to -

Wait for a user defined time and check if someone is still talking to avoid triggering on one
word or an interruption.

After a delay if no one is speaking it cuts back to a wide shot.