Help with AUM remote "mute/un-mute"

Keyb

This is what I'm trying to obtain in AUM:
to have a remote controller that sends a CC that mutes a channel and a different CC that un-mutes it.

I can mute it (or unmute it) with a single CC or I can invert its state, but I haven't find a way to do what I need.

So, to better explain, I want to be able to mute or unmute a channel, without knowing its status in advance and without opening AUM, just by sending the correct CC.

Any hint or idea is really appreciated!

Thanks, Alex

MisplacedDevelopment

You can’t query the state of AUM controls unfortunately and so if you don’t know the starting state then I don’t think there is a way of doing this simply with just AUM. There are few workarounds that I can think of, off the top of my head:

1. Write a StreamByter script which acts as a go-between that tracks the mute state and responds accordingly to each of the two CCs. IIRC, you can have StreamByter save variables between sessions so hopefully they won’t go out of step.
2. Use the channel volume control and set to zero for mute or whatever the default is for unmute. To manually control the actual volume then use the Gain AUM FX plugin.
3. Do the opposite of (2) and control the Gain plugin via CCs to mute the channel. This lets you use the channel fader control as normal.

espiegel123

@keyb: if you use a single CC you can mute and unmute as you want. Send your CC with a value of 127 to mute and 0 to unmute. You don't need to know the state of AUM.

Say you use CC 60. Sending CC 60 with value 127 will always mute and sending 0 will always unmute as long as you do NOT turn on cycle or toggle.

uncledave

You can do this by simply using the value of a CC, 0 for unmute, 127 for mute. I suspect it switches at value 64. The pic shows CC1 able to mute and unmute channel 1 just by sending 0 or 127. Note that this is not a toggle (Cycle), just a straight CC value.

Keyb

@MisplacedDevelopment
Your idea is clever and simple at the same time! Thanks!

@espiegel123
Didn't realize that! Thank you!

Keyb

@uncledave
Thanks!

wim

@MisplacedDevelopment said:
You can’t query the state of AUM controls unfortunately and so if you don’t know the starting state then I don’t think there is a way of doing this simply with just AUM. There are few workarounds that I can think of, off the top of my head:

1. Write a StreamByter script which acts as a go-between that tracks the mute state and responds accordingly to each of the two CCs. IIRC, you can have StreamByter save variables between sessions so hopefully they won’t go out of step.

For this approach, tracking the state isn't needed. With Cycle turned off the script just needs to translate the two incoming CC's into a single CC that is either 0 or 127.

Example, in streambyter:
(Examples assume CC values sent are 127 for ON actual usage could be different.)

# Translate CC 20 127 to CC 22 0
BX 14 7F = BX 16 00
BX 14 = XX +B

# Translate CC 21 127 to CC 22 127
BX 15 7F = BX 16 00
BX 15 = XX +B

@Description
  Translate CC 20 127 to CC 22 0
  Translate CC 21 127 to CC 22 127
@End

@OnLoad
  muteCC = 21
  unMuteCC = 20
  aumCC = 22
@End

@OnMidiCC
  if MIDIByte2 = muteCC and MIDIByte3 = 127
    byte3 = 127
  elseif MIDIByte2 = unMuteCC and MIDIByte3 = 127
    byte3 = 0
  endif
  SendMIDICC MIDIChannel, aumCC, byte3
@End

espiegel123

OP doesn’t need two different CCs for what he wants. I think they just didn’t know that with cycle and toggle off that a cc value of 127 always means mute and 0 always means unmute regardless of the current state.

wim

@espiegel123 said:
OP doesn’t need two different CCs for what he wants. I think they just didn’t know that with cycle and toggle off that a cc value of 127 always means mute and 0 always means unmute regardless of the current state.

@Keyb said:
This is what I'm trying to obtain in AUM:
to have a remote controller that sends a CC that mutes a channel and a different CC that un-mutes it.

[post edited to clarify]

... the rest of the discussion happened while I was testing those scripts. I only saw the conversation had moved on after I posted the scripts written based on the OP's assumption. Good to see they're not needed and a simpler answer was found.

Keyb

@wim Thanks for you script, it's indeed useful to understand a little bit more on how to handle this situations!