In the short term, one solution is to not use I/O in individual rackspaces but rather just send all audio to global rackspace. In the global rackspace, you would connect the “From” plugin to the audio interface and so when you change over, you would only need to change things in one place.
Not perfect but perhaps a reasonable workaround until we have better support for this
In fact I don’t have to make any changes in the global or indidual rackspaces as there are only two audio outputs from the global rackspace, already.
Just the settings in the “audio options” for active channels get lost. Then offering me 16 inputs and 16 outputs again, including the full meter bridge in wiring or setlist view, of which I need only two.
Not really a problem but one point to enhance.
And I explained that that was due to Kontakt trying to load/unload samples between Scenes (not good) and followed up with that if you select Forte to load all the samples needed for a show/set/file/whatever and keep them in there, Forte will switch instantly, just like GP does.
Forte does not need any type of Predictive Loading feature…because at startup you load one master Rack of plugins, and with every new Scene, Forte handles the patch changes, the MIDI channel changes, the controller assignments, etc. There is no Bypassing of plugins, there is just muting, or not assigning it to a controller.
This is a fun excercise…but at the end of the day it’s a moot point. Forte is DEAD.
Fortunately former Forte users are not, and if they bring nice idea and suggestion to the GP community this can only be valuable. 
Thanks @David-san…I have no desire to be dead yet!
OK – while we certainly don’t want to harp on this stuff forever, I got curious I did a quick experiment, essentially emulating the approach that Forte takes.
I created a new gig file with a single rackspace. The rackspace has four plugins (Lounge Lizard, Pianoteq, MiniMonsta and Oddity). I created 12 variations, each of which loads different presets into the plugins. Those are essentially the same as Forte “scenes”
As you can see from the video, it took 1.5 seconds to load the gig file. If I had 200 variations, that would not have impacted loading time in any significant way. The time to load actual plugins is by far the only significant contributor to load time.
Switching from one variation to another (thereby changing the presets in all four plugins) was essentially instantaneous (the plugin editors themselves take a moment to update their views but that doesn’t happen if the plugins aren’t open, which would be the case in a real situation)
If I add Kontakt to the mix, that will add another 5 seconds or so to the load time (as it would in any plugin host as that loading time is totally attributable to the plugin)
Adding other stuff to each variation (scene) such as setting MIDI channels, defining splits, would add essentially zero to the loading time and would have negligible impact on switching.
Hi Joey
Excuse my long rave…but Im with you: I too had a forte background for a long time but went a completely different way with Kore/live and all sorts of permutations for a while.
There is a lot of great replies…great to see you are a Korg guy!!! I still have some of the hardware…which thankfully Korg had the forsight to allow the sysex to load straight into the plugs.
Because GP allowed it so easily; I went with the persistent/modal approach using global/local rackspaces which developed out of a number of years of trial. What I mean is
PERSISTENT:
2 ‘Strips’ of persistent (chn 1 and 2):
1. Piano only; this is wrapped in Kore with 1x2 matrix morphing between a ‘band/accompanying’ piano, ie minimial sustain/no sympathetic resonance and brighter morphing non linearly through to a solo piano with the inverse, adds a lot of sublties and darker etc. This is connected to 1 widget which modulates the morph so its a single knob, same place everytime etc
2. This is the persistent pad; polysix with a similar morph to the above
MODAL
and then 2 strips of modal (ie change etc on strips 3-4)
3. The ‘main’ synth not always wrapped in Kore but it contains the main layers/splits etc with the same mod 1/ mod 2 as the earlier ones. This has a graphic keyboard and names the splits and layers so Im reminded graphically on song startup (a little like Forte background) but more concise and its active to so playing show the layer etc in realtime
4. The ‘special’ channel; using percussive or atmos etc. We use multi keys during playing so I quite ofter will use that channel split/layered where I play percussion or other stuff.
This is based on actual psychology re left vs right brain and muscle memory and after many years, it does really work
Now how that would translate to your application Im not sure, but switching load up etc is very quick and comparative to my memories of forte when doing it this way; hopefully makes sense…
What it means too is that you are only using GP at its best…as the conductor and hub for control.
It extends to controlling my in ears (using the encoder on the keys) etc so its cut so much stuff down into the simplest rig so far but Im not quite there yet…still ironing stuff out and I guess you have already worked that out ie “garbage in =”
Changing your gig set sounds like a huge job…hope you had plenty of coffee on hand and some form of mediation to reconcile yourself lol.
We dont play covers exactly and most is spontaneous stuff that is the segues etc…so it needs to be a lot more pliable too; I dont know if that is part of what you do?
My takeaways in hindsight;
Which I do from the song and go backwards if you know what I mean ie jam it out and then save back.
Anyway…hope that helps in some way!
All the best.
M
PS. This setup is across multiple teams so it seems to only take a couple of minutes to explain it and they are able to run it quite easily…always a good test re: simplicity
There is a lot more to it re: realtime audio Bokeh etc ie pulling elements into background/foreground but if interested just pm…
This is exactly what I do…as in the above mentioned setup (I didnt go into the audio) but it works nicely and remaps when plugged into alternate controller
@Aurasphere - Mark…that is an amazing post. Thanks for your insight. I will admit it is far beyond my scope at the moment. I am only working with GP for about 3 months now, and in all honesty, I started by immediately diving in and programming instead of experimenting because I wanted the new rig to be ready for Jan, 2022. So I missed a lot of quality time just getting to really know the bones of GP. Of course, by now I am familiar with all of its general features, but hopefully someday I will get to know it more in-depth.
@dhj - of course, your suggestion of passing everything through the Global Rackspace would essentially emulate (at least to a user on the front end) the routing of Forte, and could potentially really speed things up. The only question I would have would be how to handle the patch changes.
The way I have been programming, for each rackspace I would load in a plugin (say the M1) and assign it a sound, be it preset or custom. Then for the next rackspace (or another one anywhere in the set) if it requires another M1, I do the same. They are independent. In Forte, it’s only one M1 throughout and for each Scene that requires a different patch, be it custom or preset, Forte handles it. All I have to do is create a new Scene, assign the sound and controller commands and hit Save. Forte does the rest.
How could GP handle patch/sound changes for a single instance of a plugin that is mounted in the Global Rackspace? I am assuming if GP can do it with a synth, I could also load in for each instrument an FX plugin and have GP handle it the same way. This is academic for me right now…I am not in a position to start from scratch again. However, if it is possible and GP can do this consistently and with reliable stability, I may look to it in the future.
Why is a fast load time important to me? Because a crash on stage is not IMPOSSIBLE. It can happen, for whatever reason. In all the gigs I did using Forte (hundreds)…I had ONE live crash. I was able to restart Forte and be back in the tune within 8 bars of music! If I were to crash with GP, currently I would be out for over 3 minutes.
Thanks for the discussion!!
Joe
You could start a 2nd instance of GP with the same Gig File.
I will likely be at about 32 GB of RAM when my file is finally complete…that’s not practical for me to run 2 of them concurrently.
You could use Predictive Load
I could…but to me as a layman (ie: not a programmer, just a performer), I would think that if I could just have all my plugins in the Global Rackspace and GP had the ability to bypass them, reroute them, and patch change them “in status,” that would ultimately be more efficient than having rack upon rack of separate instances for any given plugin.
You know how many times I see “loading MiniMonsta” while my GIG file loads, passing through each rackspace!!! LOL…
I like to have separate rackspaces.
What do you do when you want patch persist within the same plugin?
So play a chord for example on OMNISPHERE, press Sustain, switch a preset and play with the new sound, but the held chord should remain playing?
That for certain is a great feature. But one I really don’t use or need.
I am likely in the minority for that one, no question.
Actually, I just used a single regular rackspace. And the point of doing that we solely to demonstrate that Forte is not doing any magic that lets it load faster than Gig Performer can if we restrict significantly the available functionality of Gig Performer and just allow Forte-like functionality.
Among many of the reasons we don’t advocate this particular approach (no patch persist, limited number of plugins, no multiple topologies, thereby losing significant functionality) is because we discovered a long time ago that plugins do not always handle patch changes well - some of them simply crash, others just don’t work. Given that reliability on stage was the original primary goal for developing Gig Performer, we did not initially provide any mechanism to change patches, presets, etc.
If you watched the video I posted, then you’ll see that the patches were changing. So in Gig Performer 4, we have added some interesting, though still experimental, features to deal with patch changes. Right now, as has been the case for many features that are now built-in, this is done through GP Script.
There are two functions:
Both of these are documented in the System Function list
SelectPreset works only with VST2 plugins and, assuming the plugin supports it, lets you select a preset by number
LoadGPPreset will in principle work with any plugin. Simply save the plugin state using Gig Performer’s Save GP User Preset mechanism and then you can reload that state whenever you want. While we have not yet heard of any crashes with this mechanism, the jury is still out as to the reliability of this mechanism. Plugins are required to handle the reloading of their state at any time but some developers, well, just don’t implement and test it properly.
In other words, if you use this approach, your mileage may vary – don’t call us 
(other than to set us know which plugin crashed so it can be reported to the developer, who might or might not care)
I was using this second mechanism for the video demo emulating Forte. For convenience, I named the presets 0, 1, 2, 3, … (note that presets for different plugins get stored in the right place so that there’s no conflict). This approach allows me to use a simple GP Script where I just load the preset for each plugin using the newVariation index as the plugin name.
Once we are comfortable that this mechanism is really reliable, we’ll expose the mechanism directly in Gig Performer so it will not be necessary to write even this simple script.
Yes, I did see the video David and the switching. I just had no idea as to how to go about programming that. Since you “scripted it in,” if I understand your last post correctly, that would explain how.
As I said earlier…it’s all academic for me now. I’m not turning back! But you never know…someday!
Joe
Joey, xpansion, Angel and all other contributors to this thread,
Thank you all for this very thoughtful and thorough discussion. Especially you Joey for starting it, and for the others that contributed. I’m still a Forte user, and I remember several of you from the Brainspawn forums. I’ve been dreading switching for years, but know I have to get started. Should have done it during the COVID shutdown, but procrastination, of course. It’s just not something I’m looking forward to doing. And, to be honest, I was hoping maybe someone would come out with a “converter” that could take a Forte rack and turn it into a “Gig Performer” equivalent. Or a Cantabile or Camelot converter. And, I’ve been waiting to see which of these various programs are the best to switch to. I pretty much decided Gig Performer looked like the best platform to move to more than a year ago just based on reading the forums and looking at the focus on the program and pace of development, and that still seems to be the case. I would be interested to know if anyone knows of someone that was a Forte user that went with a different platform like Cantabile or Camelot. But I think I’m going to go forward with Gig Performer, especially seeing this thread and knowing there are folks here that really understand what Forte was, and can give me some pointers based on the pain of their conversion experience.
My band is a cover band (washparkband.com), playing funk/dance/rock from 70’s to today. We’re a 12 piece with horns, I’m the only keyboard player. My Forte rack file is 75MB, and takes about 1 minute and 45 seconds to load. It has 35 “Modules” (which are basically the VSTi plug-ins), and each “Module” then has several VSTs in its effects chain. The rack has 127 Scenes, and I typically use one Scene per Song. The rack takes up 3.998GB of memory when initially loaded. Because my rack has been in use for years, and because of Forte’s limitations, I have several versions of the same plug-in for backwards compatibility. For example, I have 4 instances of Pianoteq; 3.5., 4. 5 and 6. This is because my existing Scenes didn’t load properly when a new version of Pianoteq came out. Similarly, I have several instances of Kontakt as well; Kontakt 4 and Kontakt 5. This is not only for the above reason, but also, because of the limitations several of you mentioned about the dangers of loading samples at random times (can cause crashes), I have several instances of Kontakt that load at the time of the initial startup of my Rack, and do not change. I have other instances of Kontakt that do dynamically load from song to song. Switching between songs takes one second up to maybe 3 or 4 seconds max.
I typically use two keyboards on stage, and many splits amongst different songs. I also have a 16 pad drum panel that I use for percussion (I still use an Open Labs Neko as the controller, another beast that will soon bite the dust).
Joey, you mentioned that knowing what you know now, you would put more plugins into the Global Rackspace and supplemented along the way. This is an important architecture decision I would like to get correct from the beginning. How would this have affected you, had you done it this way? Loading time between songs? Rack creation time for new songs? I would appreciate any specifics you can provide to help guide how I go about this. It does seem tempting to just build one Rackspace for each song, using only the VSTs needed for that song, including the effects. But it’s going to take FOREVER to build 127 Rackspaces. I say it’s tempting because one of the biggest problems I have with Forte is that because it loads everything at the beginning monolithically, I’m bumping into system resource limitations. Not just memory, but lower level problems like heap and handle problems. So the idea of trying to recreate a monolithic approach like Forte probably doesn’t make sense. But having to literally build a Rackspace from scratch each time doesn’t sound great either. I realize I can probabably meet somewhere in the middle; build a Rackspace that is comprised of the instruments I use all the time, and then just copy that Rackspace song to song, adding the unique instruments I need for different songs. That will likely be my approach. And then maybe I put some of the effects into the Global Rackspace. Certainly the limiter, and some basic processing like reverb, echo, etc. can probably go into the Global Rackspace. But I would love additional insight as to what should go into the Global Rackspace vs. the individual Rackspaces.
Already just by reading this thread, I have a much better idea how to approach this, but any additional insight would be appreciated!
The first thing I recommend is don’t think in Forte’ terms or how Forte’ works. I wasted a few months because I kept thinking in Forte’ terms instead of thinking in GP terms. Luckily, I eventually embraced the differences and moved forward. The second thing I would recommend is not loading instruments into the global rackspace. During my conversion from GP3 on Windows to GP4 on Mac, I took that same approach. There was certainly a time saving benefit in terms of ‘pre-loading’ a bunch of samples into a
global instance of Kontakt, there are many other pitfalls to that approach, and I’ve abandoned that approach at this point.
GP will simply not load a rack as fast as Forte’ did. That’s okay. It is a different animal. It does so many more things than Forte’ ever dreamed of. If memory management of samples is any issue, use the predictive loading feature. Even then, your gig file will likely load slower than your Forte’ racks did, but again, it’s okay.
As far as a Forte’ to Gig Performer ‘converter’ goes, it is a great dream except for one thing. The paradigms on which these two hosts work is so different, you would likely get a converted file that still ‘thinks’ like Forte’ when the GP way is actually better. Last but not least, the Forte’ format is intended to be (and is) proprietary. The author intentionally did not release the source code or any information on the proprietary formats. I tried to convince him to open source the code since he was shutting down, but he chose not to.
X
This is basically how Forte used to save the state of its plugins. They called the data “blobs.” And like you say, some plugins don’t report and/or load their state very well. It’s nice that you’re planning to have this functionality, but Gig Performer has the flexibility so that if this doesn’t work reliably with a certain plugin, one can just handle that plugin through a separate Rackspace for the songs that need it. Nice.