Forte < Gig Performer 
Fair enough, Forte is not Gig Performer. And yes, it is even better… there are a lot of great things about GP, not the least of which it is still in development and supported. But that does not mean every idea in Forte is wrongheaded or not worthwhile.
I understand that using racks to change presets is the preferred method and works wonderfully for many users. But I think there are also many who, like me, do not work to a set list and or have different working methods and performance needs. I do not think it is or should be such a big deal to send PC messages to plugins. Forte had some great MIDI routing features… as mentioned above and some things I miss, like PC messages can treated differently from different controllers and so on.
Don’t get me wrong, I think GP is great! And there were certainly things in Forte that I had a problem with. I’ve been able to do everything I need to in GP, but that does not mean everything was especially intuitive or that there might not be some easier and more effective ways to achieve some things.
Forte never crashed onstage on me, so far neither has GP. But Forte had some great ideas…and way before pretty much anyone else.
1 Like
This is possible with Gig Performer via Scripting or via Widgets for example
I want to be very careful here. My “Forte ≠ Gig Performer” point was intended to mean that they’re different in the sense that apples and oranges are different and there’s little point in trying to treat an apple similarly to the way you would treat an orange. Although @edm11’s comment is appreciated, I’m not trying to say that we are better (or worse) but what I do want to say that our approach is philosophically different and so generally one shouldn’t try to use GP the way they used older systems. The downside of sending program changes to a plugin (which you can most certainly do in Gig Performer) is that the plugin will often not respond immediately and you may very well get glitching depending on how particular plugins handle program changes. One of big benefits of GP is its ability to switch sounds on the fly with no glitches and that goes out the window if you “work around” the system and do direct program changes.
Can you explain this please?
You might want to read this article we wrote comparing rackspaces vs. program changes.
The information in the article is very helpful! Thank you!
Just FYI in the article where its says: “Here, I have dragged three patches into the program number list…”
I think there is a photo missing related to that sentence.
Darn Wordpress issues, thanks…I’ll look into it.
Can you please explain what you meant by, “PC messages can treated differently from different controllers and so on”?
This is fixed now - all images are back.
1 Like
To explain myself and agree with with @dhj at the same time 
I only used Program Change in Forte for my multi-timbrel samplers (VSampler and Kontakt).
1] I guess this would not make sense in Gig Performer (unless maybe only after there is a “Global Rack” feature).
2] Beyond that, I do think once I have gotten used to the reliability of predictive loading (i.e. “stop my baseless concerns that it might crash” 
), I might never actually need/use “program change” in Gig Performer.
Well that’s the thing that confuses me… I never had any problems or glitches in Forte sending PCs to plugins, and they always responded immediately. It appears that Cantabile provides for sending PCs to plugins, without protestations.
Likewise you could also do the equivalent of using racks to change plugin presets if you had wanted to in Forte, just using scenes. And Cantabile as well, with songs or states or whatever. So I just don’t see why this is such a big deal in GP either way…
On the other hand, the Widgets/Front View is a big benefit, for me, and one I can’t get with those others. A while back I was going to insert Blue Cat Remote in front of Forte to try to achieve the same thing, but I love this in GP. But at the same time, there are probably many who aren’t really tweaking things on stage or whatever and this isn’t a big deal at all for them… and in fact perhaps it’s more hassle than just enabling MIDI learn on plug in, moving knob on controller and done.
I guess I’m just saying everyone is different and I’m not sure the best approach philosophically is to only support one supposed best way of doing things…
In GP all PCs being sent from my controllers can only be on or off, with all PCs going first to GP and then an option to send unused PCs on to plugins. In Forte I could designate a controller and MIDI channel to send PCs to Forte. Everything else I could route PCs however I wanted.
I’ll tell you what though, I would love to get on board with using rack spaces to change presets… and not be the pain in the ass I must seem to be. It is not the concept that doesn’t work for me, it is just that I am not able to make it work with my stage setup and requirements. Right now I can access 128 various combinations of sounds very easily with a maximum of two button pushes. I can not do that with 128 rack spaces, it needs to be hierarchical. So for instance, I would need 16 basic racks but within those racks I would have nested racks, sort of like variations. So something like one controller’s PCs or say particular MIDI channel would only access the 16 basic racks. And PCs from my other controller or a different MIDI channel would only access the nested racks under that particular active basic rack. (just to be clear, those 2nd sets of PCs are always going to be the same #s which is why just 128 rack spaces won’t work and have to address just the subset of the active rack). Is there any chance this could be done with script… or you would consider it for GP?
But that brings up a second thing that confuses me. How long is it going to take to load 128 racks? It already takes a minute for the 12 I’ve built so far, which can already seem much too long sometimes. VB3 has some ambient “Leslie noise” and I can hear a snippet of that noise when racks containing it are loading (maybe GP should be mute itself when loading?)… so anyway, does that mean an instance of every plugin is loading multiple times for every rack it is in? Forte just loaded one instance of all the plugins and then it was just either enabled or disabled for each particular rack or scene. Whatever it is it doesn’t seem to create any problems at all in GP so far for me cpu-wise, but what about with 128 racks? But I am also thinking that the nested racks would not need to load additional instances? Also making loading a bit quicker?
We didn’t say you can’t do it ---- you can (and that blog article explains how). We simply note that when you use that approach, you’re at the mercy of the plugin. Some change immediately (and quietly), some change slowly (and quietly), and some of them go crazy (particularly if you were playing a note while sending the program change).
Consider just one scenario: you have configured a bunch of parameters in each of 50 plugins so that they respond to various MIDI CC messages that you send from your controller. Now you show up at soundcheck and someone hands you a different controller to use (perhaps yours broke, or you’re on tour and you’re getting controllers via backline). Now you have to learn how to edit that controller so that its knobs, buttons and sliders send out the right CC messages on the right channels. I don’t know about you but figuring out how to configure a strange controller quickly, even if the manual is available, is not fun when you’re under pressure. On the other hand, if you have used the Rig Manager in Gig Performer, all you have to do is have the Rig Manager learn the new controls and all your widgets, which control parameters of those 50 plugins will just work. Doing this can take less than a minute or two. The separation between physical controller/widgets and widgets/plugin parameters is key to being able to do this.
You could actually accomplish this right now by configuring Rackspaces so they use a different bank and then use scripting to receive program changes and do whatever you want. Having said that, we will probably change this though for the next major version so that if Gig Performer is configured to receive program changes from selected controllers, then PCs coming from other controllers will just go right through to MidiIn blocks so that we can support this legacy use.
Great question — turns out we discovered that Windows file handling seems to be significantly slower than OS X. So we’ve developed a neat optimization that significantly reduces loading time on Windows. All going well, you’ll see that update in the next week or two.
You can’t do Patch Persist ™ if you only have one instance of a plugin available
Switching to another rackspace does not change presets of a plugin, it uses completely separate instances.
All great answers… and I really do appreciate you taking the time to address all I had to say. And yes, I have always understood that there are very useful and practical reasons for the preferred working method for GP.
But there are trade offs to everything. And although maybe it is a minority of us, I only ask for understanding that I and maybe others may have different but perfectly valid priorities… that really don’t have anything to do with old school thinking, it is just different performance requirements.
But anyway, I’m not sure if you answered my main question…which would in fact allow me to work in the preferred manner. I would need a way to access a set of racks and then a subset of each of those racks. Again, when addressing the subset racks, I will always be sending the same exact same PCs. So for instance, main controller PC selects Rack 1… when in Rack 1, PCs 1, 2, 3… from second controller (or different MIDI channel) select Rack 1.1, 1.2, 1.3 etc. Then main controller selects Rack 2, GP will receive same PC 1, 2, 3… from second controller (or alternate MIDI channel) and needs to select Racks 2.1, 2.2, 2.3… (not 1.1, 1.2, 1.3…). Anyway to achieve this with script? Or maybe you would consider applicable for GP?
Will this be settable per instance of globally for all instances of GP?
I’m handling more sophisticated MIDI routings (like the one @LilyM described) in a separate instance of GP which controls my “main” instance. So it would be very useful (for me) to handle PCs from some ports just in one instance.
Yes, each instance in GP is essentially a completely separate application with its own settings.
1 Like
Great design 
@djogon Just wondering if no response means “No” ? In regards to finding a way to access different racks with basically the same PC message. I know most users seem to work in a more sequential, linear way, but a hierarchical approach would allow me and maybe others to take full advantage of the approach GP prefers and supports.
It means he’s travelling (sigh!)
I don’t know what it means to use the same PC message to go to different rackspaces? How would you to which one to go?
As for hierarchies, rackspaces have variations. Songs have song parts, and each song part is a rackspace with variations. Song parts can override variations as well.
Forte crashed for me onstage multiple times… One of the big things my band has commented on since my switch to GP is how they don’t see me stress out because my virtual rack crashed.
1 Like
The easiest way I currently see to do this (if you want to keep sending full program changes from each controller), is by combining multi-instance support, OSC and GP Script:
- Your main instance does all the audio processing and MIDI I/O except for program changes. It should actually completely ignore program changes (none assigned to rackspaces or songs and not passed on to plugins)
- You declare a second instance which consists only of a single rackspace with just two MIDI in blocks, each for one of your controllers, and a script which handles the program changes coming from your controller. In GP script, you can differentiate between program changes from your different MIDI in blocks (= different controllers). You keep a list in that script which assigns a rackspace name to each combination of program changes.
On incoming program changes, your script matches the name of the rackspace to be loaded and sends an OSC message to the main instance to activate this rackspace.
You’ll have to put in a bit of work to set this up initially, but once it is up and running, you can edit all your PC/PC-to-rackspace-assignments easily from a single place (the list in the script).
This is essentially how songs and song parts work already. Assume that you will never have more than 10 (I picked that at random) parts (they are not racks, GP is not Forte😜)
Simply start your program changes for songs at PC 11
Then, inside each song, the parts (each of which represents a rackspace/variation by the way), can be addressed directly using PC 1 to 10, or by using 10 CC numbers…the design was influenced by the needs of guitar players using footpedal controllers to send MIDI commands
This was a major goal of Gig Performer. When I’m up on stage, the last thing I want to worry about is whether moving a slider on a controller will crash something! The stress reduction since I started being able to use Gig Performer was amazing.
1 Like