MIDI Input organisation

Even though there is a “feature” in this, I continue to start each rackspace this way. I have found keeping tabs on splits and layers quite tricky and a lot of my setups are quite complex. So hopefully this will help others.

The setup is two keyboards a lower 88 note and an upper 49 note. The upper 49 is a CME VX controller and supplies it’s control surface as a separate MIDI input. The MIDI inputs are aliased as Lower 88, Upper 49 and Upper 49 Control, for me it makes the MIDI message flow very clear rather than assigning each zone block separately to a MIDI device input.

There are a number of reasons for the MIDI setup shown:

  1. In order to avoid accidental/controller default CC messages making their way into the plugins (this has caught me out a few times) I only use widgets to map to the plugin controls when actually required. So, the “Lower 88 Performance” and “Upper 49 Performance” blocks filter all SysEx and CC messages, except sustain aftertouch, expression, pitch bend and modulation. Each zone has the expression and sustain message filtered, so it is only turned on when needed.

  2. I do not like to use multiple pedals so the “Lower 88 Perf Controls” block takes in the “Lower 88” MIDI stream and filters out Note ON, Note OFF, and aftertouch messages, leaving just the controls being merged into the “Upper 49 Performance” block. You may want to also filter the “Lower 88” modulation and pitch bend at this point.

  3. The Zone blocks all have their MIDI input set to Local GP Port and MIDI merge enabled, so these blocks are now used to set the zones and the stream is limited to just performance data. The source of the stream is also very clear. So when adding a new zone there is no issue of getting unwanted CC messages flowing into the plugins or getting the single sustain or expression pedal correctly routed. For more infomation the zone name could include the low and high MIDI note names
    eg. C1 Zone B3 etc…

It is the third point that has the feature, you cannot use the learn function when setting zones. Setting the zones must be done manually…

This is one of my rackspaces with 7 zones on the 88 note (3 sequencer triggers on the right are very small) and three zones on the 49 note. I also make use of the Note On blocking in the zones when switching variations to avoid stuck notes. The Plugin bypasses are also switched on variations to save CPU cycles when no longer needed.

GP 4.1.5


A little gotcha when using global transpose. When global transpose is set to a value other than zero, the transpose is applied to each MIDI block. Setting transpose to -1 and looking at the template above, the global MIDI monitor shows the incoming key, the performance layers (1st layer) shows the key transposed down by 1 semitone, but looking at the output of the zone MIDI blocks, the key has been transposed by down by 2 semitones. The ignore global transpose checkbox must be checked in one layer. In the template I have chosen to disable global transpose at the performance layer so that when adding a new block at the zone layer the global transpose is correct without having to remember to turn it off for each zone.

A further update for anyone using this scheme. There are a couple of problems with this approach when using MIDI Patch Persist. After discussion and understanding the workings of PP, these are the issues, they may or may not be important in your setup. For patch persist to work it must have a MIDI input other than the Local GP Port as it’s input so this stops the stacking of MIDI input blocks using Merge and Local GP Port. The second problem is masked by the first. So if you use device input and merge in the sustain pedal from a different device the persist works on the notes held but not when held by the pedal (hands off). For me this was a problem that needed a workaround, I guess it will be for people that use a separate MIDI pedal board for their sustain…

The workaround is to put some the MIDI CC filtering and pedal merge into the global rackspace and loop round via MIDI IAC (Mac) or virtualMIDI (PC). Where “Lower Board Performance” and “Upper Board Performance” is a safe filtered MIDI stream and “Lower Board Perf Controls” is used to filter out the MIDI notes, aftertouch and channel pressure from the lower board while keeping the sustain. This gets the filtered and merged stream onto a single specific deice input.


This new MIDI device is now available to use on the MIDI IN blocks in any rackspace and carries the input correctly so that Patch Persist now works with a pedal from a separate MIDI source. What has been lost is the clarity of the connection source which I liked, now the source has to be identified in the MIDI Input block name. But by doing this and only using these new virtual devices your setup only requires just one sustain pedal, patch persist works and is is impossible to get to a gig and have rogue CC messages arriving at your plugins.

For convenience I also use rig manager to map the virtual devices to a sensible name. Where the “Performance” indicates to me this is an input stream with just realtime keyboard controls. Any other controls needed can be mapped via widgets.

rig manager

Hopefully this will help someone on their way to fame and fortune!!

1 Like

Hmm, I’m a little confused now – I thought you were doing something different. You shouldn’t have to do any of that.

Consider the following rackspace in a gig (see below)
Here, I am using a keyboard for playing and I am using the sustain pedal from a MIDI pedal board (GT-Mastermind)
Patch Persist is enabled

For the keyboard, the “sustain” is being blocked (that may not matter if that particular keyboard doesn’t have sustain). For the sustain pedal, everything except sustain pedal is blocked (in my case, that’s just to prevent other CC messages from being sent from the pedal board)

If I play notes, hold the Sustain Pedal down, release the keys and then switch from the Pads rackspace to the Acoustic piano rackspace, the organ (Blue3) chord that I was playing stays on until I release the sustain pedal.

Thanks, that is sort of where I am at now, by putting it in the global rackspace, I avoid having to do it for each rackspace, just pick up the two streams one for each board, filtered and mapped to taste. The ultimate goal was to just manage zones in each rackspace without having to think too hard about the filters, and merges. This gets me simple rackspaces with no merges just zone mapping and no danger of rogue CC messages. It is all working sweetly now, Just not as visually stimulating as the nice connected stack I started with :slight_smile: