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)