That sounds like a Dugan automixer, named for its inventor Dan Dugan. Except instead of controlling audio gain, you're using the internal control signals to switch cameras. Same logic to create those control signals.
Problem is, the patent is still valid, and the inventor is still making a living on it. So you'll have to either buy something that satisfies his license and figure out how to use it, or license it from him yourself. Probably not going to happen for this plugin.
The original invention was entirely analog, as a standalone 19-inch rackmounted thing to plug into the channel insert jacks of an analog mixing console. In terms of "conventional" audio processors, it's a cross-coupled ducker/expander. Each signal has a level detector and a gain element (analog VCA, or voltage controlled amplifier), but they're all connected so that each channel's increase causes its own gain to increase (expander) and all the others to decrease (ducker). That "voting" happens simultaneously for all channels, and the results are summed to control each VCA. The result is that the loudest one stands out and the rest fall away, and the rates are designed so that the total of all gains running in parallel stays constant.
I think for the plugin to do all of that directly, would infringe on the patent. But it would probably be okay to compare arbitrary things - it doesn't do that yet either - and it only happens that audio level is one of many arbitrary things. Better still, to avoid a mess of cross-comparisons, would be to do some math, store the result in a variable, and then compare anything to that variable.
For example, sum a bunch of audio levels, divide by a constant (start with the number of inputs used, and adjust as needed), store that, then compare each level to that (modified) average. But again, it would require some functionality that (to my knowledge) doesn't exist yet.
A long time ago, when
@Warmuptill was switching from the old single-function tabs to macros, I made the case for arbitrary programming, like Python or similar. So there'd be a General tab, a Macro tab, and a Python tab, or whatever capable language. Still have a menu for everything that the API offers, but each menu item simply inserts the code required to use that API hook. The user still needs to make the connection.
I think the "compare multiple to an average" function would be one of the stronger arguments for that, because the menu structure to do all of that directly would get to be a mess pretty quick...unless that's *all* it does, which is getting dangerously close to the patent IMO.