FR: automatic audio input mute state driven by Mackie Universal Control

Hi Gunnar,

This feature request is about studio-style talk back control driven by DAW transport (tape style talkback).
I do have this working on my desktop at the moment by using several different tools to achieve the same result, but, I believe, Streamdeck MIDI plugin is the best place for this.

So, in a nutshell, I would like to have MIDI plugin automatically mute/unmute default windows audio input based on Mackie's MIDI signals. When DAW is stopped, (MIDI-in received 905D7F on channel 1), then, input (talk back microphone) should be unmuted, and, when DAW is playing, (MIDI-in received 905E7F on channel 1), then, the input (talk back microphone) should be muted.

This Streamdeck button should be ARM/DISARM (ON/OFF) for this whole functionality. So when disarmed (OFF), then, nothing happens whatsoever (all MIDI input is ignored). But, when armed (ON), then, MIDI in should listen for those Mackie events and execute Mic mute/unmute depending on MCU transport signals.

In some cases, depending on whether collaborators are using headphones or speakers, the unmute part should not execute. This is to allow participants to do push-to-talk but still have the plugin mute their mics when DAW playback starts.

For starters, the audio device muted/umuted can be a simple default windows audio input. Later on, if possible, you could add selection of audio device to be controlled.

The way I see it, the controls for this Streamdeck button would be:
- MIDI IN Device (dropdown) where users choose on which device to listen for MCU events (it has to be shared with all other MCU buttons so that both standard MCU controls and this talkback control can work at the same time)
- Mute on Play (checkbox) where users choose if they want the plugin to mute the mic
- Unmute on Stop (checkbox) where users choose if they want the plugin to unmute the mic
- [optional] Audio Device (dropdown) where users choose which audio device should be muted/unmuted this way.


Here is my usage scenario:
I have an internet-distributed band that I am making some music with. All of the members are scattered around the globe. We have one powerful machine to do mixing and we use Reaper as a DAW and TeamViewer/AnyDesk/TightVNC for controlling the machine. We use Sonobus or Audiomovers ListenTo to send PCM audio via internet to all parties. For communication, we use Mumble. We also use Bome Network for MIDI-over-IP to be able to control Reaper transport via Mackie Universal Control. Luckily, Reaper can have an unlimited number of Mackie Controls added so we have no problem with ports sharing.
Now, when Reaper is stopped, everyone can unmute themselves and discuss whatever they want to discuss. When Reaper is playing, everyone is muted so we all hear just the output from Reaper with no disturbances from anyone's microphone.
I've managed to automate this using MicSwitch and MIDIKey2Key where MIDIKey2Key is listening for MIDI events and translating 905D7F and 905E7F to F14 and F16 while MicSwitch is set to mute the microphone on F14 and unmute on F16.
As a bonus, we are also using Streamdeck-AudioMute on one of the Streamdeck buttons for visual feedback about the mute state of the microphone and for manual mute/unmute/push-to-talk operations.

So, the best way to consolidate all this and get rid of MicSwitch and MIDIKey2Key requirements is to have this functionality built in as a dedicated button in your MIDI plugin for Streamdeck.

Looking forward to hear your thoughts about this.

Thanks!

P.S. Here's a pic of my Streamdeck.

Thanks for your thorough description.

To be honest, I think it is too much of a niche application for a dedicated Stream Deck action.

I have been thinking about building an action that might be possible to use for such a scenario, but it is very far from "decided." I have been thinking of what it would take to build an action similar to BarRaiders Super Macro, but for Midi. It wouldn't be as streamlined and straightforward to use as what you describe, but it would be far more flexible. But I must emphasize that there are no plans or decisions made. I haven't a clue what it would look like or what features it would have. It's just an idea that has been lurking in the back of my mind for a while.

Just in case someone comes here searching for the same thing:

I built a tiny tray helper for windows in AutoHotKey which translates MIDI Mackie transport stop/controls into regular keyboard presses. These keyboard events are then recognized by Mumble to execute self-mute (in case everyone else can automatically mute themselves) or alternately, to execute self-deafen (which bothes mutes self and everyone else at the same time).
By using this tray app I don't have to run MicSwitch and MIDIKey2Key anymore.

Cool, thanks for sharing your solution.