I LOVE Vmix shortcuts and Activators - especially their flexibility. I'm also often really frustrated by them.

I have three Xkeys controllers and now several hundred shortcuts and activators - and as much as I try to use very logical naming conventions and re-order the shortcuts to group like things together, it's not nearly working as well as I would like - especially in the following areas.

1. Many of my shortcuts use the same key, so they execute at the same time. For example, to create a sort of IFB (Interrupted feedback)/Intercom to use with VMix Call guests, on one Xkeys controller I have 8 different buttons to turn on the the following functionality (and another 8 buttons to turn them all off) - and on another controller I have 20 inputs to do the same thing (so that I have a defined range of inputs within which to use the (up to) 8 Vmix Call inputs) - with different input ranges for different types of production needs:

- For each input; simultaneously turn off audio, turn on solo, turn on the directors mic, director's mic to solo, change Vmix Call return audio to "headphones"
- For each input; simultaneously turn solo off, turn off the director's mic, turn off solo for the director's mic, change Vmix call return audio back to "master"

As you can imagine, each individual function requires its own shortcut (9x28=252 in total) and cloning and editing each of them, for each of 56 buttons (28 on and 28 off) was a huge pain. I would have really appreciated the opportunity to create a single group of these and then specified duplicates for each vmix call input. That would really help on the organizational front too; grouping and sub-grouping or nesting these groups into named sets or categories, much like an outline.

2. While I've been pretty successful in creating a 32 input Xkeys video switcher using shortcuts (including a pair of keys for volume control that can be applied to any input currently selected in the Preview bus) , my attempts at making an audio mixer in the same way still presents some significant challenges. Primary among these is that the ability to select an input and then perform a function on it requires that the input be in the Preview bus first. That works fine when you're switching video, but not well when there's a separate operator adjusting audio (bus assignment, volume, input gain, input on/off) - he can't change the input in Preview without the director/TD being aware of it, or the TD will hit the "take" button and end up with a different input on Program than what he attended.

So, if there's any way to define an input that you'd like to act upon in some other way than putting into Preview first (like some kind of phantom bus or variable), that would solve this problem.

3. I'd also love to see activators get the same kind of organizational functions described at the end of #1 above; outline-like nesting and grouping prior to cloning (with an ability to reference a single input).

Any thoughts or work-arounds from the community would be appreciated.

Thanks!