How I'm using GSi VB3 with gig performer effectively

Thanks to you too for sharing the way you are working. This is interesting for the GP community as sharing is what we do here :wink:

2 Likes

Just one more tidbit of information regarding the files that VB3 references that are global to all instances and may solve the dilemma of why isn’t a particular global setting that is saved not reproduced ? The manual refers to the existence of the file(s) but as far as I know only the FAQ here actually points to those locations .

The manual states
" THE GLOBAL SETTINGS WINDOW

This panel shows the global settings that are stored in a separate file and affect the overall operation of VB3-II."

the FAQ then includes " Q: Where are the support files of VB3-II located on my disk?
A: VB3-II stores some files in a system directory that is automatically allocated by the operating system.

Under Windows it should be:
C:\Users{ your user name }\AppData\Roaming\GenuineSoundware\GSi VB3 II\

Under OS X it should be:
/Users/{ your user name }/Library/GenuineSoundware/GSi VB3 II/"

for my own particular needs I find the Settings.xml has the settings that I require.
"

Tuning (A=Hz)
Upper MIDI Channel
Lower MIDI Channel
Pedal MIDI Channel
Lower Octave Up if Split
Receive MIDI Program
Enable Organ Preset Octave
Reverse all Drawbar CC
MIDI CC #64 Function
Output Level
Edit Windows Always On Top

"

Once those settings are edited and saved , “0” for no check mark , “1” for check mark I assume
The state of those settings are now reflected when the plugin is opened .

That’s correct, you can change the global settings by editing the file text. However, you can also change the global settings in the plugin itself by opening up VB3 in your DAW of choice (any that is not gig performer, since I have still not figured out how to overwrite global settings from gp - maybe the devs can shed some light on why that’s the case) changing the global settings in your VB3 instance, and saving the DAW project file. This will overwrite the global settings file without risk of writing improper syntax that messes things up. That being said, this is still valuable knowledge as it would be best practice to save a copy of your global settings file when you’re sure it’s correct so you have a backup to reload in case settings are unexpectedly modified or you want to be sure your global settings are consistent right before a performance.

1 Like

Does the new vb3 version suffer the same issues?

Afaik, yes. From what I remember, the gist of what the dev of VB3 says is that this is a feature, not a bug. As in, it is intended to operate with these quirks, despite it causing a bit of a headache for us gp users.

What’s the benefit of that being a feature?

You don’t have to fix it. :grinning:

1 Like

That was a serious question. What is the benefit of that stuff being global and not saved as part of the state?

1 Like

It’s been awhile since I researched this and unfortunately I couldn’t find the forum thread where the creator of VB3 was chiming in himself. However, from what I vaguely recall, VB3 is designed primarily as a live organ emulator with all the controls and drawbars mapped to a midi controller for use as an organ emulator. I believe the thought was that someone would adjust global settings to their liking and specific setup and then not have to adjust them again for individual presets, or have the plugin reset to default each time a new instance is loaded. I believe a similar reason exists for why multiple instances of VB3 may have trouble saving their state in that it was designed to only have one instance running at a time. While obviously many people (including myself) have plenty of use cases where they would want multiple VB3 instances running at once, all with different global settings, that was not the intent of the creator and so my understanding is that it was programmed this way. I have not looked at the code, nor do I have much experience programming VSTs to know for sure, but I would guess that designing it this way allowed for significant performance gains. To its credit, once VB3 is loaded, preset switching is the most instantaneous I’ve ever experienced in a high quality VSTi and once you get acclimated to its idiosyncracies, VB3 can be very user friendly. It’s just in certain scenarios like this when it becomes extremely user unfriendly.

Again, I’m paraphrasing something a long time ago that I didn’t look much into at the time, so I could be misrembering or misrepresenting what I read. But thought I’d chime back in since no one else did.

I doubt that — particularly when used with Gig Performer and the entire state of each instance is generally loaded in advance.

Fair enough. I’ll try to revisit the thread if I ever find the page I was talking about and hopefully that sheds more light than I can.

thanks for this. I agree the MVintageRotary is a nice alternative to the VB3 leslie. I tried running them both using the direct organ outputs and thought they actually sounded pretty fantastic together.

Since I first jumped into this thread back in May of '22, GSI has updated the VB3. Among other improvements, the quality of the internal Leslie simulation within the plugin is now good enough to my ear that it precludes the need for a separate third party Leslie. This not only simplifies the GP rackspace but reduces CPU load as well. So I’ve gone back to just using the updated VB3 on its own, and the sound stands up quite well, especially in a group setting.

I went back and listened again to the old stock Logic Vintage Organ plugin last week. I have to say, the Leslie simulation built into that old plugins still beats nearly everything out there now, but the updated GSI VB3 is the single plugin winner for me for both overall Hammond sound and Leslie emulation.

Having owned various real Hammonds and Leslies since the 60’s, I’m picky about emulations, and still waiting for one that makes me smile like the real thing. Meanwhile, GSI VB3 does the job for me.

Did you try IK multimedia Hammond plugin?

Yes. It’s OK, one of the better ones, but GSI VB3 is still the overall winner for me. It can scream and howl in quite a satisfying way.

Understand, but the ik Leslie is by far the best

“By far?” To each his own.

The IK Leslie is good, maybe better than GSI, but I would say not as good as the old Logic Leslie. I particularly don’t like the IK on fast speed.

Just for reference, over the years I have owned a B2, a BV, a couple of B3s, and my favorite of all, a 1941 BC with double tone generators, to which I added a Trek II percussion and a vibrato scanner salvaged from an old C3. I’ve also owned various 122 and 147 Leslies.

My dream rig? An old double tone generator BC like the one I had, with added touch response percussion and a smooth knob vibrato scanner, blowing through two Tall Boy Leslies modified for both slow and fast speeds. I would be in heaven with that, and might have to get there before I ever see it! LOL.

Enjoy your IK, I’ll enjoy my GSI, and maybe one day we’ll make music together. Thank you for your many helpful contributions to GP.

You are right, such things are personally taste.
Like we in Bavaria say
“Die Katze mag Mäuse, ich mag sie nicht”

3 Likes

I’d like to implement the solution in the first post to deal with GSi VB3-II issue with a Rackspace Script or Scriptlet. It seems that VB3-II reverts to the default patch when Gig Performer is first loaded, so we need to send it a PC message to load our desired preset.

With a Rackspace Script, we have the On Activate callback, but it doesn’t seem that it can send MIDI messages directly to a plugin (even with a handle).

With a Scriptlet, I can send the message directly into the MIDI input of the VB3-II block, using a “wire”; however, this doesn’t work within Initialization. I ended up initializing a variable (fixed : boolean) to False. I also create my desired ProgramChangeMessage during Initialization. In the NoteOnEvent, I check if “fixed” is still False. If so, I set it to True and send the Program Change message. I then send the NoteOn message in all cases.

This has the artifact of screwing up the first note or so, but if I remember to hit a quick staccato note before the song, all is well.

This avoids using a MIDI Out block, which I’d like to avoid for various reasons. With a Scriptlet, I can target each VB3-II plugin independently.

I do not understand, why load a preset?
Normally the state of a plugin is stored within the rackspace section of the gig file.
So when the gig file is loaded the correct settings of the plugin should be loaded, independent of the shown preset name in the plugin.
Or do I miss something?

1 Like