Controller scaling

General discussion about Gig Performer
1

Is it possible to scale controllers in Gig Performer? For example say I want a controller pedal to increase the amount of delay from 0-127 by the time the pedal is halfway down. Then on the second half of the pedal throw I want the level of a distortion plugin to go from 0-127. Or perhaps I want the delay to go from 0-127 as the pedal moves down, but I want the distortion to go from 127-0 (the opposite direction) at the same time. Can this sort of scaling be done?

Thanks for any help.

2

The second scenario you described can be achieved very easily: You add a widget for each parameter you want to control and map all of these to the MIDI signal from your pedal. You in the mapping dialog you can also scale the controller input linearly.

The first scenario you described is a bit more complex as it involves non-linear scaling which is currently not supported natively. If you need that kind of stuff right now, it can be done quite simply via GP Script :slight_smile: (If you need help with that, feel free to ask!)

3

Thanks for the help on this. So with the help of a script it is possible to have one controller move two different plugin parameters in opposite directions and it’s also possible to scale them non-linearly?

How about this scenario The controller moves a plugin parameter from 0-127 as the pedal moves from all the way up, to 75% down. Then during the last 25% of the pedal throw the parameter suddenly moves to 0. At the same time during that last 25% pedal movement, a different parameter goes from 0-127.

I use the above scenario a lot in MainStage. But overall MainStage is pretty flaky hence I’d like to move to Gig Performer if I can achieve these kinds of controller moves.

4

Controlling multiple parameters with a single controller, each with its own linear scaling (including an own direction for each) is possible directly via the GUI. The big difference to MainStage here is that you‘ll have a separate widget for each parameter mapping instead of the MainStage way of one widget for the controller which includes all the parameter mappings.

What is currently not supported via the GP GUI is any kind of non-linear transformation (like going from 0 to 0.75 to 0 again). That’s where you‘ll need GP Script :slight_smile:

1 Like
5

Simon, sometimes when the venue provides a piano I just use my controller, in which case my expression pedal is plugged into the controller rather than into my main board. When plugged into the controller though, the expression pedal is totally out of whack… with most of the full range of 0-127 being sent happening within the first half of travel of the pedal. I would love and appreciate the help if there was a way to address that easily with script… but I don’t have the first clue when it comes to that.

6

Thanks simon,
How difficult is it to program a script to do something like this: During that last 25% pedal movement, a parameter goes from 0-127?
I’m not a programmer but I understand some simple java script, at least to the point of being able to copy a script and change the relevent numbers. Do you somehow attach a script to a widget?

7

I’ve built a small example for two parameters mapped to the same expression pedal:

  • one parameter stays at 0.0 for the first 75% (0-95) of pedal movement and goes from 0.0 to 1.0 during the last 25% (96-127)
  • the other parameter goes from 0.0 to 0.8 in the first 75% of pedal movement and from 0.8 back to 0.2 during the last 25%

grafik

Note that parameter/widget values in GP are floating-point numbers from 0.0 from 1.0, whereas MIDI input data are integers from 0 to 127.

The function performing these transformations is straight-forward:

// we're assuming here that your Exp pedal is generating MIDI messages
// on CC11 of a MIDI port which is received by the MidiIn block in
// connection view.
on ControlChangeEvent(msg : ControlChangeMessage) matching 11 From MidiIn
var exp : integer
    newVolume, newBalance: double

    exp = GetCCValue(msg)  // exp is now a 0 - 127 integer value
    
    select
        exp <= 95 do
            newVolume = 0
            newBalance = exp.Scale(0, 95, 0.0, 0.8) // map the MIDI values 0 - 95 to the parameter values 0.0 (0%) - 0.8 (80%)
        exp >= 96 do
            newVolume = exp.Scale(96, 127, 0.0, 1.0)  // map the MIDI values 96 - 127 to the parameter values 0.0 ( 0%) - 1.0 (100%)
            newBalance = exp.Scale(96, 127, 0.8, 0.2) // map the MIDI values 96 - 127 to the parameter values 0.8 (80%) - 0.2 ( 20%)
    end

    VolumeWidget.SetWidgetValue(newVolume)
    BalanceWidget.SetWidgetValue(newBalance)
end

I’ve also attached a gigfile including this function as a reference:
MultiNonLinearWidgetMapping.gig (6.8 KB)

8

By the way, you can mention users much easier with the @ notation, for example: @Antiphones

9

I know that problem which comes from multiple pedal and keyboard vendors using different impedance ranges for expression pedals. That’s something that you would ideally fix on the hardware side (e.g. Nord keyboards offer different presets for different pedals). For fixing it in software, there’s two things to consider:

  • For your use case, you would probably want a global mapping which applies to all rackspaces and would not have to be set up for each rackspace individually. As scripting in GP is currently only applies for individual rackspaces, doing it the way I described above is not ideal. Instead you could use an additional “proxy” GP instance with a single rackspace doing the MIDI transformation and sending it to the “main” instance.
  • On the software side, not everything can be recoverd at all. If the full range of 0 -127 is sent to the computer in the first half of pedal travel, the computer can’t possibly discern any of the pedal states greater than half-pressed, because your keyboard won’t be sending any MIDI messages for any position in the second half of travel.
10

Huge thanks for this @simon it’s really appreciated! That code makes sense to me, I think I can work with that. Do you attach this code to a widget somehow?

11

@simon thanks for the thought you put into tha!! I will contact Novation and see if there is any fix on their end. I did not see anything in the manual.

I don’t mind setting something up for each rack space, but your last point is well taken. I’ll have to check more closely with Midi.Monitor to see exactly where in the pedal travel the 0 and 127 messages are being sent. Thinks again!

12

I have run into this problem with physical pedals quite often ---- I got a new pedalboard recently and then discovered that my old pedal (which worked great with my previous pedalboard) was only going from about 40 - 125

Then I got a pedal that was recommended for use with the new pedalboard and it goes from 0 to 127 as expected.

13

@dhj You are correct, sir. Not sure why I would have thought there would be some sort of standard implementation for this sort of thing… but of course they all work differently. The only expression pedals that will work properly with Novation gear is M-Audio EX-P or Moog EP-3. Brilliant. Makes you appreciate what an amazing achievement the MIDI standard was/is.

14

@simon How do you attach a script to a widget? I see a field under Properties / Advanced called OSC/GPScript Name. But this doesn’t look like a place to paste a script. Thanks.

15

There is no attach to a widget.
The script reacts on actions fired from widgets or midi messages.

16

When you have a rackspace selected, click on Window | Show Script Editor

17

A script is always attached to the rackspace. The script is running/watching in the background for things to happen in the rackspace. This name-field is used to define a name with which you can address this widget in your script.
So you could let your script “listen” to the pressing of the button named “btn_1” or the switch named “carl” (whatever name you gave it :wink: ).
Those names are also available for all of the plugin blocks you can see in the “wiring view” on the back of your rackspace. If you want to work with any of them in a script then it is mandatory to give a name to the used element.

18

@schamass Thanks that makes sense.

19

@dhj Ah I see, thanks.

20

@simon In your script it looks like this just acts on any incoming midi on CC11 regardless of which widget is attached to that controller. Is that correct? In which case I’m guess I don’t need to name the controller in the OSC/GPScript Name field?

I’m guessing I just paste this script into the script editor window and it will work?