Controller transformation for program change

Keep in mind that if you are testing this with a gig file that has 8 rackspaces, the widget knob will move through all 8 rackspaces by about 0.6 on the knob markers (out of 10).

You can alter this behaviour by using the widget scaling.

See if this example gig works for you. I provide two widgets, one that has the widget scaling applied, so the full rotation of the widget will move through rackspaces 1-8. While the second widget is the default (which will support moving through 128 rackspaces).

SystemActionsPC.gig (133.6 KB)

I have checked the behaviour of the program change parameter now on two computers (Windows 10 Pro, 64 Bit). On both computers with the GP-versions 4.0.54 and 4.1.5 the program change parameter doesn’t switch rackspaces.
But I have defined now buttons on the Twister for previous/next rackspace and previous/next version. This might be useful in some situations. Maybe I will also check the direct access to rackspaces to use the fade-in/fade-out behaviour more appropriate.

Concerning the rackspace script: The scaling is an interesting idea but both widgets don’t change rackspaces in my environment. Of course the left encoder with scaling enabled shows constantly the value 0 while the right widget shows changing values.

Something has to be wrong. There’s no way GP doesn’t respond to program changes unless something is configured wrong. Have you actually assigned program changes to the variations in your rackspaces? Did you make sure that you’re in the right mode (zero based or one based) for program change numbers? Did you send a bank select command by mistake?

I cannot find it anymore in the community forum, but I remember @npudar made a kind of tutorial regarding everything that has to be done for PC to work flawlessly. (quite a few options to remember).

You mean the latest blog?
Link: Gig Performer | How to send Program Change messages out to hardware devices and other applications

Yes, not exactly the current topic, but an overview of everything you have to think about when it comes to PC👍

1 Like

I have checked the situation a little bit further. I might have to add that I’m working with the Gig-Performer version licensed by Plugin Alliance. But for me it seems that everything concerning handling is the same as in the original Gig-Performer.

I checked the SystemActionsPC.gig-file provided by rank13 and learned how scaling is working, interesting feature.

Also I checked the program change behaviour with this file. As MIDI connector to the outside I have a MIO USB-interface:

For sending program changes to my PC over the MIO interface I use a Korg FC6 footswitch:

For receiving program changes from Gig Performer I have a Yamaha MU-80 which shows changes on the display:

I have seen the following things:

If I change the setting “Use zero-based PC numbers”, the visible numbering of the rackspaces changes. The technical parameter value in the background remains the same starting with 0 for the first value.

Even with this gig-file not created on my computer the encoders are not able to switch the rackspaces. But the rackspaces can be controlled by external program change commands. The Global MIDI monitor shows incoming program changes, and the rackspaces are switching

The program is reacting on incoming program change commands over MIDI. The Global MIDI monitor shows activity when I press one of the switches on the FC6:

If you look at the encoders in the screenshot you can see that they correspond to the program change values. So it looks that the encoders can’t switch the rackspaces but the program changes are able to switch the encoders. Not exactly what I’m looking for at the moment but maybe useful for future applications …

If I switch rackspaces manually with the mouse I see no reaction at first on the encoders.

But as soon I move the left encoder manually to any direction (in this case towards the lower values) it picks up the current rackspace value:

Additionally I tested the MIDI-Out behaviour. I activated the program change numbers 1 - 3 for the first three rackspaces in an additional MIDI-Out widget I added to these rackspaces.


The sound selection on the MU-80 was changing according to the chosen program change values, but only when changing the rackspaces by mouseclick in the program.
When switching rackspaces over the FC6 footswitch the name of the desired sound is shown shortly on the display and then switches back to the first value, just if a kind of reset is sent after the program change. I have found no setting which blocks this “reset”.

But currently this is not important for me, just an observation.

For now I can say if I would like to use program changes on the stage for rackspaces without using a mouse I should use an external program change device.

Yes, that’s how it is supposed to work.

So I am completely confused as to what you are trying to accomplish. Can you explain briefly?

Sorry for confusion.
I want to use the Midifighter Twister on the stage as external controller for Gig Performer. Unfortunately it doesn’t send program change messages.
I tried to link it to a widget to be able to change rackspaces with one rotary encoder.

Currently it seems that an external device must send a program change directly. I found no other possibility to redirect other controllers to program changes within the software (except using the next/previous rackspace functions).

I just have seen this here:

System Actions (

•ProgramChange - displays the current program change number (use in a label).

In my case it would be useful to have a program change function which is able to work in the opposite direction (that the change of a single controller can be redirected to program changes for switching rackspaces).

Hmm. Well my example gig file was using this to actually change the rackspaces, and was working correctly.

Ok, it’s not a big problem now because I found a usable arrangement. Also I have seen that controller changes and program changes seem to be seperate kind of data. There are additional informations by Controller 0 and 32.

But something might be different on your system. I checked it on three PC’s with different amounts of installed software, always the same effekt.

Are you working with a PC or a Mac?

I remember something additional. When I load your gig-file I get additional warnings:


Maybe you have some additional code in these files which enables the function for you?

You can just open the gigscript and delete the include statements there to remove those warnings.

There are two ways to accomplish this if your external device can not be configured to send real program change messages.

  1. Use a gigscript to convert some particular incoming CC message (e.g. CC 42 on channel 8) into a program change message. That conversion happens very early and so Gig Performer proper will see the generated program change and respond accordingly
  2. Map a widget to the Program Change parameter in a System Action plugin. Make sure that you do this only in the global rackspace.

CC 0 and CC32 are interpreted as bank select commands - this is part of the MIDI standard. They don’t actually change anything by themselves but when a subsequent program change is received, the combination of those CC messages and the program change will drive what is actually selected. Any synth module that supports multiple banks (i.e, more than 128 patches) works this way.

So I tried to write my first Global Rackspace Script. I found this thread here:

Gig Performer | The GPScript Programming Language

and thought it could do the work if I modify the script a little bit. But it always gives me compilation errors when I try to activate it.

I tried to get the situation like in the shown configuration. So I set a GPScript Handle Name and activated “Use in GPScript”. Now my Midi-In-block looks like the Midi-In-block in the Legend-configuration.

Then I tried to modify the presented script that it reacts on controller 127 and switches to the rackspace number of the controller value. I tried to use parameters that I found in the callback-list (
and list of functions (

Does this script show at least a little bit in the correct direction or is it completely wrong?

The test for equivalence in the IF statement is ==

If thisNumber == 127

You also shouldn’t have those prefixes on the arguments you’re passing to the SwitchToRack function (this function is also deprecated and is now SwitchToRackspace.

SwitchToRackspace(thisValue, 0)

In line 19?

Improvement, but now a different message: