How to get an Instance to respond to only one midi channel?

Hey guys! I’m new to Gig performer and trying to figure it out. I am doing okay so far, but I have a few things that I can’t seem to get working.

When I enable Multi Instance from the advanced settings tab, how can I get the new instance to respond to only one midi channel?

Thanks for the help!

In the Midi In Plugin you can disable single channels

Yes I have done that, but the instance is still responding to PC (program Changes) from all channels. I want to change Variations independently on this new instance.

Bill, can you provide more info on exactly how you’re trying to set things up and what exactly you are trying to do. Gig Performer treats program changes specially and generally ignores the channel on which they come in. Are you trying to send program changes to two instances of Gig Performer from a single keyboard?

Dave thanks for the info on how GP treats program changes.

Here is what I am trying to accomplish.

My keyboard is a Kurzweil PC3x. I have all my splits/layers programmed in it.
Each layer/zone sends to a specific midi channel. The midi from my keyboard goes to my rack.In my rack I have a Mac Mini which is running multiple banks of Kontakt on 5 midi channels. I also have a Muse Receptor running 9 different plugins on separate midi channels. This allows me a lot of flexibility to put together splits and layers from a large palette of plugins and sounds with little to no load time since I am just sending prg changes and not loading plugins . My plan is to replace the Receptor with GP.

In GP I have one single rackspace that holds 10 plugins. I am sending program changes from the PC3x to individual plugins on separate midi channels just as I was doing in the Receptor. This is all working fairly well. There are a few plugins that do not have their own built in patch lists, so I was trying to run another instance of GP and use variations to create a “patch list” so to speak for them. Now that you tell me that GP does not “channelize” patch changes, but ignores the channel on which they come in, I guess this wont work.

Any other ideas?

I solved it!

I used Midipipe to filter only midi channel 8 out a midi out within Midipipe creating a virtual midi in to GP.

Then I created a new instance of GP that responds to midi and program changes from MIDI IN (MidiPipe Output 1). Now the separate instance has a rack space for each of my programs!

In the process I did unearth a problem. I am sending midi clock from my PC3x. When I created the virtual midi in from MidiPipe GP saw two incoming midi clock signals. It made the tempo display a tempo twice the value/speed that I was sending. I was able to correct this by filtering out Timing Clock in MidiPipe.

Problem solved!

1 Like

I’m glad you worked it out — I’ve added a request into our bug tracking system so that incoming MIDI clocks will only be “recognized” on a single port. That will stop the incorrect tempo issue.

We’re also going to add the ability to restrict program changes to a single MIDI channel, not just a single MIDI port. We hadn’t thought of your use case but it makes perfect sense.

2 Likes

@Bill I was not in time to suggest MidiPipe as some last resort - there is also MIDI Patchbay http://notahat.com/midi_patchbay/

@David As far as restricting program changes goes I was wondering if it could be part of the midi filter that is already included, and have it work on a per instance basis.

Hi Bill,
Clearly we can do whatever we want from a technical perspective — the issue here is really more philosophical and how we prioritize what we develop. When you use GP in its intended manner, you get a ton of benefits including such things as patch persist and predictive loading without any delays or glitches. The problem with changing plugins patches directly is that they won’t all respond instantly, nor silently in some cases. Many plugins don’t even support presets in this manner at all as the mechanism was not really intended for real-time use.

From our perspective, it’s sort of a question as to whether we want to be Microsoft or whether we want to be Apple. The former has gone out of its way to make new products be completely compatible with old stuff whereas Apple’s perspective is to dump stuff (serial port, floppy drive, CD ROM, 32-bit programs and so forth) that it feels is no longer important. The consequences are that Windows is this huge legacy beast while Apple is more easily able to stay ahead of the curve and innovate.

So, for example, we believe it’s really important that a musician should be able to switch instantly from one sound to another. We feel that features like Patch Persist are very important in a live situation. Neither of these is possible in a model that allows plugins presets to be changed so we don’t want to encourage that approach.

Of course the risk is that this may make Gig Performer less attractive to users who may be just trying to recreate an “old” environment.

On the other hand, although it requires some extra work on the part of the user, everything you’re trying to do could be implemented already in Gig Performer as it exists now using GP Script, the scripting language that was introduced in Gig Performer 2.0 and while GP Script is still evolving, with some basic programming knowledge, it would be pretty easy to write some scripts that would recognize incoming program changes, distinguish them by their MIDI channel, and send the appropriate Preset messages to plugins directly. One of the many reasons for developing GP Script was to allow corner cases such like this one to be feasible without “interfering” in the direction in which we’re trying to take Gig Performer.

For example, attached is a screenshot of a GP Script that receives program changes through a MidiIn Block whose GPScript handle is “Keyboard”. There are three plugins with GPScript handles called “FM8”, “Blue3” and “Massive”. When a program change is received, the script examines the channel number and sends the program number to a different block based on whatever was the channel number. This probably solves your problem completely.

(Sigh - turns out that when I wrote this 5 minutes ago, I discovered it didn’t work, due to a minor bug in the scripting system around program changes that nobody noticed before now. I just fixed it so this script works now but unfortunately people will have to wait for the next GP update to get this fix and that’s a few weeks away due to some vacation schedules)