MIDI Toggle of Buttons Broken?

The Virtual Audio Mixer discussions and support...
lifewithmatthew
Posts: 15
Joined: Fri Dec 04, 2020 6:26 pm

Re: MIDI Toggle of Buttons Broken?

Post by lifewithmatthew »

Hmmm.... I think zero should still be processed though. If I'm doing a momentary button then it sending zero (that is it is no longer being pressed) is an event I would want processed, especially for something like PTT or Solo. If I'm using a remote device (such as my android app, or a physical MIDI controller for audio control at an event) then I want to make sure that I can glance at my interface and know for certain that someone has a mic that it hot or muted and not have to guess about how many times I pushed a button.

Maybe I'm thinking about things backwards here though and would be very interested in what more experienced users would expect and how they use MIDI controllers as I am very inexperienced.

Thankfully, your previous post did get something to click! I set mute up to be a PTT button and then inverted the signal coming from my 2 position button such that it behaves in the manner I expect (when I click the button in my app Strip #1 is muted and the app shows mute as being slected, when I click the button in my app again Strip #1 is unmuted and the app shows mute as being unselected). For me personally, I would like to see the mono, solo, and mute buttons all have the option to be latching (that is to have the same function as PTT currently enables), but at least this gets me past this initial hurdle.

Also, a few posts back I mentioned that I wasn't getting any feedback from MIDI output. I spoke with dev team for the app I use and they currently don't use the MIDI feedback function, but are looking to implement it in a future build so not an issue with voicemeeter.
xcasxcursex
Posts: 139
Joined: Tue Feb 18, 2020 12:04 am

Re: MIDI Toggle of Buttons Broken?

Post by xcasxcursex »

My experience with hardware is that the switches are almost always momentary in hardware, and send a value reflecting their physical state (ie 7f when pressed, 0 at release, messages being sent on edge transition for interrupt-driven pins, or whenever the pin state is polled and has changed. I can remember ONE device that had hardware two-position toggle switches, and they sent a note-on event at both extent, and a note-off when leaving that extent, thus emulating the momentary switches' behaviour but allowing a big fat on/off switch.

This simplifies hardware (remember, this is from an era of discrete electronics, and maybe 8 bit IC's if it's fancy) because everything works in a manner where effectively, the midi value whether note or velocity or CC or aftertouch or whatever, is a direct representation of the voltage at the hardware pin.

For multi-throw (eg toggles, three position, eight position, etc), the logic of the virtual switch position (ie, is this guy muted or not?) is handled by the receiver in the manner suggested by Vincent above (ie only listens to the note-on events to change state).

If there is a feature to monitor the state of the virtual switch, the state is output to listening devices, ie it sends 00 when not active, 7f when active, and then this signal can be used as desired by any listening device (ie light an LED, or update a menu text, to let you know that the mute switch is active - or in some cases this signal actually actuates the electronics eg the value it sends is used to drive a relay/transistor which cuts off the mic - the signal is not just a monitor, it is the physical control)



They mostly do it this way. Mostly.
lifewithmatthew
Posts: 15
Joined: Fri Dec 04, 2020 6:26 pm

Re: MIDI Toggle of Buttons Broken?

Post by lifewithmatthew »

xcasxcursex wrote: Thu Mar 11, 2021 1:50 pm My experience with hardware is that the switches are almost always momentary in hardware, and send a value reflecting their physical state (ie 7f when pressed, 0 at release)
Interesting, so did the hardware you use provide any button to mute a channel beyond holding down the mute button for however long you wanted it silenced? Or is it that the mute button would light up on one press and go dark on the second press and you just had to assume the light was indicating the correct state?

If you were using midi for a button on VoiceMeeter, would you expect it to process the value zero when you released your momentary button or would that cause VoiceMeeter to behave in a manner contrary to how you're used to midi devices working.

(Also, as a side note when I was talking about a toggle, I didn't mean a rocker switch, just a button that would alternate, or toggle, between on and off each time you pressed it. A latching button might have been better thing to call it.)
xcasxcursex
Posts: 139
Joined: Tue Feb 18, 2020 12:04 am

Re: MIDI Toggle of Buttons Broken?

Post by xcasxcursex »

Yep, most of them work that way (as a mute toggle, rather than hold-to-mute). Some devices will often support either a toggle like this, or a hold-to-mute (common in broadcast situations where someone might say a naughty word and you need to silence things briefly), or a hold-to talk (common for communications where you want to keep the channel clear unless you intend to communicate, like a walkie-talkie), or any combinations of the three.

Some devices will toggle an indicator LED and also send the message, when you press the button. This is problematic because there is always the chance that the indicator LED state is not synchronised with the actual state of the mixer - as in, the mute LED might indicate that the channel is muted, but perhaps the mixer never got the message, or perhaps something else toggled the mute on the mixer later, so either way, the mute is actually not active but still the LED is lit to indicate that the mute IS active. Obviously this sucks and is a bad way to do things.

The best and most common way is for the button to send the message (say, a note-on) when it is pressed (and then a note-off when it is released - reflecting the physical state of the button). Then the mixer receives the note-on message and mutes the channel, and ignores the note-off... then the mixer sends a message (say a note-on) to inform other devices on the buss, that it has muted. Then the other devices on the buss toggle the indicator LED to show that the mute is active on the mixer. This is much better because everything is actually sending messages that reflect their physical state. The message from the mixer tells you when the mixer has muted. The message from the controller tells you when the button is pressed. The LEDs on the controllers are set by the mixer, so if you have two controllers with mute buttons and one mixer, the controllers also control each other, and the LEDs will always be in sync with each other and the mixer. If something goes wrong, and a device is unplugged or doesn't receive a message for some other reason, whenever the state of anything changes, it will send it's physical state over the midi buss and that will update everything and it will all be in sync.

This kind of approach has another benefit -the same controller button is equally useful no matter what it is controlling. Say, you have two buttons on your controller, and two controllers, and a mixer. The mixer can now support a hold-to-mute AND a mute toggle. If it wants to do hold-to-mute, then the mute state of the audio channel will be muted when the button is held, and not muted when it is not. Both controllers' LED will light up when you press this hold to mute and both LEDs will turn off when you release the button, and both controllers' LEDs will show the same state which matches the mixer. You can press the other button on your controller, and the mixer will take the note on message as an instruction to toggle the mute off, and ignore the note off message, and the controllers' LEDs are both still in sync with each other and the actual mute state of the audio channel.

Now the devices can do intelligent things like having one controller button have multiple functions. Let's say you push and release the button (just tap it). Now the mixer mutes the channel. Now let's say you push the button and hold it. The mixer can see how long you are holding the button, and because it doesn't receive a note-off message yet, it knows you are push-and-holding the button. Now it can temporarily un-mute. Now you release the button and the mixer sees tht you are no longer holding, and returns to it's mute state. Now you push and release the button, the mixer sees it is a quirk tap, and toggles the mute state, leaving it un-muted again. Now you press-and hold the button, the mixer sees the push and no release, so it acts as hold-to mute. You release the button and the mixer sees the note off message and knows you are not holding it so it un-mutes. The whole time, the mxer is sending note on/off messages to control the indicator on the controller, so the controller always tells you if the channel is muted or not. This kind of thing is only possible if the messages reflect the physical state of the devices.

There's nothing objectively wrong with having the logic of the effect of pushing the button, determined by the controller. It can be useful. But to have the logic determined by the mixer is FAR, FAAAR more powerful and flexible and reliable.
xcasxcursex
Posts: 139
Joined: Tue Feb 18, 2020 12:04 am

Re: MIDI Toggle of Buttons Broken?

Post by xcasxcursex »

To answer your question directly:
If you were using midi for a button on VoiceMeeter, would you expect it to process the value zero when you released your momentary button or would that cause VoiceMeeter to behave in a manner contrary to how you're used to midi devices working.
I guess ultimately, both messaages should be recognised, and then the type of button would determine whether they cause any action.

If you choose a 2-position macro button, then note-on messages would toggle the button on, and then toggle it off, and note-off messages would be ignored. If you choose a push button, then the note-on messages would always toggle the button on, and note off messages would always toggle it on.

This is very quickly heading into the territory where some kind of scripting language is a necessity, and it is a feature that has been requested, and does exist to an extent. While you have no power for scripting in the macro buttons app itself, what we do have, is the VM API, which can then be used by an external application, which performs the scripting that handles the logic to respond to midi messages, then controls the state of voicemeeter or the buttons. If you wanted to get complex handling like this working, you could go so far as to write a custom application, but I think the fastest way to try it, is with the VMR AHK wrapper and one of the autohotkey midi handlers.
lifewithmatthew
Posts: 15
Joined: Fri Dec 04, 2020 6:26 pm

Re: MIDI Toggle of Buttons Broken?

Post by lifewithmatthew »

That was a very comprehensive response, thank you!

Hopefully in the future we see options for zero values being processed and some of the advanced features you were mentioning incorporated. I am glad that in the immediate sense I was able to work out that setting VoiceMeeter mute strip to be PTT gets it to operate in a manner like I was expecting!
xcasxcursex
Posts: 139
Joined: Tue Feb 18, 2020 12:04 am

Re: MIDI Toggle of Buttons Broken?

Post by xcasxcursex »

It will be nice to have those features, but remember - they won't solve your problem. Your problem isn't a lack of features in Voicemeeter, it is the non-standard controller you're using:
In Midi Mixer I have a toggle button. When I activate the toggle button it sends a Control Change (CC) event for Channel 1 Data 9 with the value of 7F (or 127 in Decimal). When I deactivate the toggle button in Midi Mixer it sends a Control Change (CC) event for Channel 1 Data 9 with the value of 00.
That's really just wrong * . Your controller is acting as a controller AND it is handling the logic of the mixer. That's not it's place to do because it's not the mixer. The controller isn't actually sending messages reflecting the state of the button press, it is sending messages reflecting the state of a state machine implementing a virtual toggle switch (mute on/off toggle) from a momentary hardware switch (tapping your screen). This is why VM works when you set it as PTT, because now, Voicemeeter is not handling the toggle logic, the controller is.

Now I put that * there because that's a gross simplification on my behalf. MIDI doesn't demand that things are handled one way or the other. There is nothing technically wrong with the controller device doing half of the mixer's job... It just... is a less-than optimal solution, which is why it's rare, which is why I just abbreviate to saying "that's wrong". That kind of setup will work juuuust fine. But ONLY if the mixer expects that particular unusual configuration, and only if there are no other devices which may potentially control the mixer or controller, etc etc..... It is fine, but only in rare cases. Fortunately, it is easy to configure VM to be that rare case :)

This is like eating noodles with one chopstick and hoping for tubular noodles so that they work better. Nah you need a fork or another chopstick or something, your noodles are fine :)

I did try to look into this, because you seemed to suggest that the midi mixer app is quite powerful in allowing different behaviours from the buttons, and this is sensible because lots of gear works in different ways. I found the website and it too suggests that it can handle different configurations, but I couldn't find a manual for it anywhere. Do you know if such a thing exists?
lifewithmatthew
Posts: 15
Joined: Fri Dec 04, 2020 6:26 pm

Re: MIDI Toggle of Buttons Broken?

Post by lifewithmatthew »

There is not a manual, but assuming you're looking at the one from Volcanomobile SNC, I can configure a button as 4 different midi commands, Notes, CC, PGM, and CST. I'm using CC and it can further be configured in one of two ways.

The "Default" way in which pressing it will send a value of 127 then 0 on release. This way works, but my goal here is to not need voicemeeter visible on the screen to look over and see if I'm currently muted or active.

Then there's toggle, where pressing it the first time will send a value of 127 and pressing it a second time will send a value of 0.

For each of these modes I can configure it to invert the logic such that 0 is sent on the press and 127 on the release. Doing this along with the toggle mode and setting mute to PTT in voicemeeter lets me get the expected behavior where, provided the midi instruction was successfully received and processed, pressing the button in my app lights up mute and mutes it in voicemeeter and pressing it again turns off the light and turns off mute in voicemeeter.

I know it's a less than ideal solution but it's what I've had to do to get the two pieces of software to work in a manner consistent with how I would expect a controller to behave.

I've spoken with the app developer about getting midi responses back from Voicemeeter and it's something they're looking into doing, which will help alleviate some of the app needing to do the roll of the mixer as well.

That said, I still feel like Voicemeeter *should* be processing the zero value of a midi instruction, without 0 being processed then every button has to be pushed twice to get it to operate. But since it currently isn't I've had to do this work around.
xcasxcursex
Posts: 139
Joined: Tue Feb 18, 2020 12:04 am

Re: MIDI Toggle of Buttons Broken?

Post by xcasxcursex »

lifewithmatthew wrote: Sat Mar 13, 2021 9:34 pm my goal here is to not need voicemeeter visible on the screen to look over and see if I'm currently muted or active.
That makes sense, I mean if you're using a remote controller, you might even be on the other side of the planet and completely unable to look at VM ;)

Fortunately, Voicemeeter does have the appropriate features to support this behaviour. As per my above descriptions, the trick here is to have the mixer (VM in this case) provide acknlowledgement of receipt of the command, and feedback of the state of VM's muting, via MIDI. This is possible using macro buttons, by using

Code: Select all

System.SendMidi
to send feeback to the controller,.... Of course, the controller has to support this too, and until your software does that, you've found a very clever workaround!

What I'm trying to impress upon you here is that while voicemeeter could provide support for processing the midi value 0 message, that isn't actually what you want. It would provide you with a different workaround, but that approach would still have problems, all of which are solved by having the mixer (VM) work exactly as it does right now, but by having the controller work differently.

In other words, the real problem here is not that VM does not act upon value 0 messages - the problem is that your controller is treating the switch and the LED (really a touchscreen and some pixels looking like a button) as one device, which it isn't. It should be treating those two devices as two devices. Pressing the button should send the midi message to say you have pressed a button, and the LED should light up when he controller receives a message to turn it on. Voicemeeter should (and can, right now) mute the mixer when it receives the instruction to do so over midi, and acknowledge that action by sendind a midi message out, and then the controller can light up to tell you that the channel is muted or not, based upon that message.

This is all 'nice in theory' at the moment, but when you start to introduce other items into the MIDI environment there, it becomes critical. Think about how it would work if you decided to have your MIDI Mixer app running on your phone and also on a tablet, both controlling the same instance of Voicemeeter.
Post Reply