Unfortunately, VB3-II behaves badly (IMO). When I restart GP, the preset window at the top of the plugin’s screen shows the name of the User Preset that I had stored. I had saved my gig with that state, and all of the desired settings (knobs/drawbars) in the plugin before exiting Gig Performer. When I restart Gig Performer and that gig, my preset name shows at the top, but the knobs and controls reflect the default state. In the plugin window, if I go to the previous, then next preset, my values load.
It’s really broken. It stores my User Preset data, and it knows that my preset was the last one used, but it overwrites the controls with their default state.
An alternative way of solving it would be for me to make a ton of widgets that have values that load when the rackspace/variations load, but there are tons of parameters, and that’s not my way of working. While some make elaborate panels that reflect their plugins, I prefer to just add widgets for parameters that I will control live, or that will change with variations.
So, to work around VB3-II’s issue, and to avoid a heavy panel, I need to send a unique program change to each instance of the plugin when or after the first time that each Rackspace is activated. Unfortunately, Scriplets don’t get events on activation, and scripts can’t send PC messages to specific plugin blocks. My workaround for the workaround is to detect the very first KeyOn event and send it then.
I just tested with GP 4 and VB3-II v.2.2 and the state is loaded correctly when the gig file is loaded.
Can you upload a rackspace showing the issue and a screenshot how VB3-II should look like?
I just made a new gig with VB3-II with different settings in different rackspaces, and I did not have the problem.
I’ll make a copy of my large, performance gig and start stripping it down to see if there is a tipping point where it starts working properly again. I might have some odd interaction there, given that it evolved from a gig that used the previous version of VB3.
BTW, I wouldn’t have necessarily upgraded, but for whatever reason, the older version started crashing.
The versioning is weird. Mine shows it to be the “2023 Edition”, “Version 2.1.1 - build date: 31 Jan 2024”, “VB3-II v2.2 - 23-OCT-2023”. The Release Notes on the site show Version 2.1.1 being released on March 1, 2024.
I would guess that v2.2 is a typo, and it should be v2.0. And that March 1 should be February 1.
The AU version works properly on the Apple Silicon Mac. The VST3 version does not store the state as I reported above.
Why did I even put the VST3 version on my Mac? Because GSi changed the stand-alone rotary cabinet from a normal effects unit to something that sends the audio to an instance of VB3-II. I had some problems with it so I tried the VST3 version.
SOLUTION: On Apple Silicon Macs, use the AU version of GSi VB3-II. The VST3 version seems to have problems storing its state.
RECOMMENDATION: The rotary cabinet plugin (now called Remote Input) is not a stand alone plugin. It sends the audio to an instance of VB3-II. (You must enable Remote Input on the Edit | Effects panel of your VB3-II instance. You must then click “CONNECT TO VB3-II” in the Remote Input plugin window and enable Send Audio.) The audio with effects does not come out of the Remote Input plugin. It comes out of the VB3-II plugin. I had some reliability issues with it. Unless you want to mix your 2nd source into the rotary speaker of the organ, and unless you can get it to work reliably, I would recommend using a simpler. stand-alone 3rd party plugin for rotary effects on other instruments.
On Mac Intel I can reproduce the Issue with the VST3 version.
Did double check with Ableton Live, here the VST3 version is working correctly, the state is reloaded correctly.
