Switch expression pedal mode with GPScript?

[JoeyK]

Hi all,

I’ve finally received my Midi Commander and Moog expression pedal in the mail.
But settings this up was way trickier than I had thought. The reason is I want the same functionality as I’m used to on my old BOSS pedals.

Ok, so here’s what I’m after and what I’ve got so far:

Each rackspace will have Volume and Wah-Wah expression pedal widgets.
If Wah-Wah isn’t activated, Volume will be controlled by my pedal. If I activate Wah-Wah using a toggle widget, the pedal shall no longer control Volume. As soon as I deactivate Wah-Wah, the midi pedal will control Volume again.

This sounds like a perfect job for GPScript. But, I’m not a very experienced scripter and am having trouble finding a solution to this from the script reference.

This is what I have in my mind (this isn’t working code, this is just how I picture it would work):

var
  VolPedal : Widget //Expression pedal widget for volume 
  WahPedal : Widget // Expression pedal widget for Wah-Wah
  WahToggle : Widget // Toggle for Wah-wah effect

if WahToggle.Active = true then
   VolPedal.MidiAssigned = None
   WahPedal.MidiAssigned = CC#1
else
   VolPedal.MidiAssigned = CC#1
   WahPedal.MidiAssigned = None
end if

Does anyone have a working example of this kind of scripted functionality?

Thanks in advance!

[David-san]

What about this alternative?

@David-san

Yes, this is doable with a GPScript. But, there is a slightly different solution which doesn’t require any scripting. The idea is that if your pedal is at 0 the plugin is bypassed, if not it is active.
To do so, you can:

• use a pedal widget together with a led button
• assign the pedal to the wah parameter of the plugin
• assign the led button to the bypass parameter of the plugin
• assign both widgets to the same widget group
• invert the led button value and modify its max range to 2.0.

This is done in the following gigfile (the associated plugin is a MIDI in block, only to illustrate the principle): wah_and_bypass.gig (6.1 KB)

[JoeyK]

That’s a cool trick, but I actually want to manually activate my effects with the midi controller, not have it be dynamically triggered by the expression pedal.

So far I’ve been able to check the state of a toggle widget using this code:

On WidgetValueChanged(newValue : double) from WahActive
  if GetWidgetValue(WahActive) == 0 then
    Print("It's off")
  else
    Print("It's on")
  end
End

That was the easy part. Changing the CC# assignments is harder.
Also, I could do it a different way. The Volume pedal could always be assigned to a separate Gain controller that is bypassed as soon as the wah-wah is activated. But, this would mean it would jump back to normal volume, which in some cases aren’t what I want. Changing the midi assignment would therefore be a better solution in my case.

EDIT:

Here’s that particular solution:

On WidgetValueChanged(newValue : double) from WahActive
  if GetWidgetValue(WahActive) == 0 then
    Print("It's off")
    SetPluginBypassed(GainPedal, false)
  else
    Print("It's on")
    SetPluginBypassed(GainPedal, true)
  end
End

I might be wrong and that this might be a better way to achieve what I’m after, rather than changing midi assignments (if that’s even possible through GPSscipt).

[David-san]

I was a bit quick to answer your question. If I understand what you want to do, you can do this without scripting too.

1. First assign your pedal widget to the MIDI in block plugin feeding your FX plugin and map it to CC#7:

2. Then add a GP MIDI filter plugin between your MIDI in and your plugin and set it to concert CC#7 to say CC#12 or whatever you want:

3. Then assign the LED button to the MIDI filter plugin and map the bypass plugin parameter to it. In the value tab of the widget properties you will probably want to “invert” the value such that led LED is OK CC#12 are produced.

Then if the LED is OFF the pedal will procuce CC#7 :

Then if the LED is ON the pedal will produce CC#12

Here is the test gig file:

pedal_LED_CC7_or_CC12.gig (6.8 KB)

Does it help?

[JoeyK]

That’s really cool, I wasn’t aware of the midi filter. Thanks for taking the time to share this!

But I’m a bit confused. Looking at your gig-file, if I assign my expression pedal (real one) to the expression pedal widget, it’s still acting on it even though the midi monitor is telling me a different CC is being used. I’m not completely sure how I could use this to switch between two different expression pedal widgets.

[David-san]

If you assign you controller MIDI pedal to the GP pedal widget, it will produce CC#7 and CC#12 whatever your hardware pedal produces.

[JoeyK]

Oh, I didn’t know that. It’s always 7 and 12?
Then I guess I messed it up by learning from the pedal instead of just assigning manually from the list, as per your instructions. It’s taking me a while to get a hang of how all this fits together.

[David-san]

What I wanted to tell is that GP catches the incoming CC# from your MIDI controller to control the pedal widget, while CC#7 and CC#12 are the values chosen in my example, you can freely replace them by any other CC#xx independently from the CC# of your MIDI controller.

[JoeyK]

Ah, ok that makes sense. But after learning the correct CC from my pedal (CC#1), the midi filter started showing CC#7 even though I set up CC#1 as the filter instead of 7. But that’s just one of several weird problems that’s been popping up once I plugged in these controllers.

Right now I’m simply trying to get two buttons to activate/deactivate based on one foot switch (CC#26), but for some reason it quickly gets “out of sync” with what I’m doing on the midi controller. And the buttons each control the bypassing of their respective plugins, but this too gets out of sync with the current value of the button.

I thought my script was messing something up, but this is problematic even in the simple two button setup.

[David-san]

@JoeyK

But after learning the correct CC from my pedal (CC#1), the midi filter started showing CC#7 even though I set up CC#1 as the filter instead of 7.

Look at step 1. of my explanation, and choose CC#1 form here if you need it.
Once again the CC#1 of your MIDI controller is catched by GP to control the pedal widget and there is no more CC#1 coming out of your MIDI in block after that. So if you need to produce a CC#1 again out of your MIDI in block, the trick is to assign the MIDI in block CC#1 parameter to the pedal widget. So you regenerate the CC#1 that GP catched to control the pedal widget.

[JoeyK]

Whoops, I didn’t realize the pedal was controlling the MIDI In plugin. And that is fed through the filter based on the state of the switch LED. Ok, I get you!

[David-san]

@JoeyK

I didn’t realize the pedal was controlling the MIDI In plugin.

The idea is to MIDI learn your MIDI controller in the MIDI tab of the properties of the pedal widget. Then when you move the controller pedal the widget pedal will move accordingly.

[JoeyK]

Yeah, I know. We’re talking past eachother a bit. MIDI learning isn’t the issue, it was what I saw in the monitor didn’t match what my controller did. But then I realized it doesn’t matter which CC I was originally using, the widget controls whatever I make it control, and the MIDI filter changes that. That’s why I got 7 and 12, even though my pedal is 1.

[David-san]

Yes, you’ve got it.

• so CC#7 in my example is chosen here:

@David-san

1. First assign your pedal widget to the MIDI in block plugin feeding your FX plugin and map it to CC#7:

While the MIDI filter does the rest, but of course you have to adapt the CC#xx you want to redirect/convert to another CC#yy accordingly.

[JoeyK]

Btw, you wouldn’t happen to know what these mean? I can’t find anything on it in the documentation.
I experience a lot of issues with widgets getting out of sync with what my midi controller is sending. I’ve tried the Sync button as well (above this dropdown list), but that didn’t seem to do anything.

[schamass]

“Jump” makes the widget to instantly take the value of the connected controller.

i.e. a fader widget is at 75% and the connected controller is at 10% - as soon as you move the controller, the widget will be put instantly to 10% and from then on will be following the controller.

“Catch” needs you to move ta connected controller over the the value of the widget. In the example from above, you’d had to move the controller at least to 75% until the widget starts to move and follow the controller - so you have to “catch” the value of the widget first before it starts moving.

[David-san]

@JoeyK, the manual is your friend
https://gigperformer.com/docs/userguide/widgetpropertiesinspector.html

Behavior - Jump/Catch–This drop-down box allows you to choose between Jump and Catch modes. When a widget is in Jump mode, moving the associated physical controller will cause the widget to immediately jump to the position of the controller. When a widget is in Catch mode, the widget will not respond to the associated physical controller until the controller’s value matches the current value of the widget, at which point the widget will respond.

[JoeyK]

Thank you!

Sounds like Jump is the safest best for me.
Now I just need to figure out why my widgets ofter don’t trigger what they’re supposed to, either the plugin directly or via script. It messes up my flow and I never know if I actually activated what I wanted.

EDIT:

Pressing widgets manually works. I print the WidgetValue and it corresponds with the state of the widget (on = 1.0). But when I use the midi controller, it changes the color of the widget, but not the value. So it looks like it did what it was supposed to, but the actual value (that I look for in the script to control my plugins) doesn’t update.

My midi controller (Harley Benton MP-100, formerly MeloAudio Midi Commander) has a small display that writes what happens. It says the correct button was pressed and set to the correct value (off = 0, on = 127). But the widget suddenly tells me the opposite, even though the graphics changes correctly.

Anyone familiar with this issue?