Unfortunately, the “Program” change parameter is not exposed on the VST2 version of VB3-II plugin. It is only exposed on the VST3 version. This rack space sets up several buttons from which I can trigger Program changes from my Korg nano controller buttons assigned to widgets. Looks like I am stuck with needing the VST3 version?
Why not use different rackspaces for different presets?
Each rackspace stores the state of the plugin, no need to recall presets.
In generally you should not switch sounds by sending pc messages to plugins.
Better you build different rackspaces for different sounds.
This gets to the issue of changing to the rack space I want quickly through a single button assignment and not by pressing next/previous buttons several times. I thought it would also save memory to have a single rack space with one plugin instance where I could call up the patches I want with 8 widgets - one for each program change assigned to my controller.
The crashing of the rack space with the VB3-II organ plugin appears to be related to it also being in a set list song with a saved variation. So far today I’ve had no crashes loading a gig where the song parts have been removed accessing that rack space.
From the article it sounds like my rack space implementation is generally discouraged.
If there is way to setup separate rack spaces for each patch variation I want to use in the plugin, I would do it if I can assign the rack space (rack space variation?) to a controller button so I don’t have to hit previous/next several times to get to the patch I need.
In a set list, this is not an issue where the song and structure are known and static. But in an improvising situation, the form and structure are not known.
I think GP optimizes already the memory use for you.
You can change rackspaces/variations using program change (PC) messages,. Can your MIDI controller send PC?
Otherwise, as @pianopaul proposed… scripting is your friend.
Yes… so you’re saying to assign a program change to a rack space and then assign the controller buttons to send a controller change to Gig Performer?
Yes, that’s right.
This is typically discouraged as plugins often have problems with these operations and there is no way it telling how fast a plugin will switch its preset internally.
If you use a sample based plugin - this could take a LONG time. For a non sample based in may take less, but it will NEVER be as fast as switching a rackspace in GP which is pretty much instant and absolutely safe.
So @pianopaul and @David-san already gave you excellent advice and if you follow it you will notice that your transitions from sound to sound will be smoother. You also have ability to take advantage of “Patch Persist” feature as well as control the transitions behaviour with audio tail lengths.
Hope this helps.
The plugins in this case are modeling instruments, not sample based. VB3-II and Lounge Lizard.
It seems like far less resources would be consumed if I didn’t have to duplicate a rack space 8 times just to set a different patch in the plugin.
However, if this is the safest method I will look into assigning program changes to the rack spaces and assigning a controller to navigate.
Perhaps instead of buttons, a knob to quickly rotate back and forth through the rack spaces.
Again, I am pretty sure you should’nt think like that. GP is optimizing resources use for you.
Were you wanting to read email and surf the web while performing?
I think I just need to accept that the number of rack spaces in a gig is unimportant. My view was that one rack space with widgets to handle the patch variations is better than 8 duplicated rack spaces. I’ll look into making changes to implement the accepted model.
I have a monster gigfile of over 450 rackspaces. Gig Performer was constantly crashing until the GP developers found a crook set of plugins. These bad plugins were updated by the software writers and GP has been great ever since. I don’t use setlist mode, but load each rackspace as a separate song. I have predictive loading set to 3, and the gigfile loads in a about 3 1/2 minutes. When changing to a song anywhere amongst the 450, I generally have a rackspace load time of between 2 and 10 seconds. This works well for me. Oh, by the way, I change rackspaces using an iPad as a master midi controller over a wireless network - in this case, GP is under the iPad control.
Alan, just out of curiosity, and maybe an idiot question… But with such a big set, do you use patch persist?
Hi Dick. No I don’t. I have no need for sounds to continue as I change rack spaces (songs). As a solo performer playing basically concerts at rest homes, I usually yak a bit between songs. The yak time demands silence, therefore no need for PP. My songs are complete in themselves anyway, so each song is a new event. No need for lingering sounds.
Do you think there is a reason it shouldn’t work with a large number of rackspaces? It is supposed to work whatever the number of rackspaces.
I’m wondering if there’s confusion here between Patch Persist and Predictive Loading.
Umm, not sure I understand. My songs have an intro and always stop at the end, either with an outro which automatically stops everything, or a dead stop without an outro. Then silence. PP in my understanding, allows notes to linger whilst a rackspace is changed. Why would I want this if I use outros and dead stops! Am I confused here?
Uhm, I don’t think you would. That is why I am suspecting that you were being asked if you were using predictive loading to manage that large number of rackspaces
But I was asked about Patch Persist, not Predictive Loading.