How I'm using GSi VB3 with gig performer effectively

Plugins
1

Like some users here, I was running into a few issues when using VB3 with Gig Performer and loading states. Upon googling a bit, I found that VB3 doesn’t always behave/load/save as expected, not only with Gig Performer but other DAWs as well. I rely heavily on this plugin and use it in multiple rackspaces with different presets and drawbar settings, so I needed to be able to count on each instance having the correct settings every time to use in a live performance context. Having finally landed on a process that loads VB3 presets reliably, I thought I’d share how I have it set up for other users that may run into similar issues with this plugin in the future.

I’m sure my method is not the most effecient or clever, so I’m sure there are people here who can describe a better method, but just thought I’d share what works for me for anyone that happens to be having this issue in the future!

Firstly, it’s important to note, that VB3 saves certain settings globally across all instances, such as octave (-12, 0, and +12) and split settings in addition to some others. For example, if I have an instance of VB3 with NO split selected, and I open a second instance, turn “split” on, and save the project before closing, when I open the project again, both instances will have “split” on. This is obviously not an ideal feature for a live performance use case but it’s how the plugin functions, and understanding this can save you a headache.

Now on to the preset loading:

  • First, make sure that your VB3 settings are set to allow for program change messages to be received and that your octave below midi note #36 will control the drawbar presets if you’re going to try this method.
  • In order to correctly load VB3 presets in the rackspace, I have 2 midi in blocks going to each VB3 plug in separate rackspaces. One is my midi controller that I play, the other is a midi in block only used for controlling the VB3 presets. **You don’t have to use a second midi in block like I do, it just makes things easier ensuring that that program change messages are only getting sent to VB3. I use a dummy midi in/out created with loopMIDI. I also like using this method because I can block the lower octave on my midi keyboard to avoid switching drawbar presets unintentionally.
  • In the setlists window, I will select each song part that contains a rackspace with VB3. I edit the “midi messages to send when song part is selected” to have the song part send a program change message that correlates to the VB3 preset I want. PC 0 corresponds to preset 1, PC 1 to preset 2, PC 2 to preset 3, etc. The PC message is sent out to the same midi device that goes to the VB3 in the selected rackspace. I can also send a midi note on message to the same midi block in order to select whatever drawbar preset I’d like. This way, whenever the song part is selected, the correct preset and drawbar settings are loaded, regardless of if VB3 saved its state correctly.
  • You can also accomplish this same task by using a midi out block in the rackspace itself that sends the appropriate midi messages upon rackspace activation, though I find the song part method to be slightly more reliable and adaptive as it allows for VB3 preset changes within the same rackspace if so desired.

Hope this helps someone! Feel free to expand on/improve my method if anyone knows of a better way.

3 Likes
2

Thanks for this!

I started experimenting with VB3 a few days ago because it’s more CPU friendly than my other options. I set up a basic organ model and saved that as a preset. VB3 exposes program as a MIDI parameter, so I added a knob to my panel and am setting the program number with it (VB3 feeds back the program name). That way, I can switch presets between rack variations just by setting the dial correctly. If I need the lower manual, I send something on that channel via the MIDI in block.

1 Like
3

Have you considered switching to a plugin like Blue3 (say) that doesn’t have these kinds of issues? It seems to me you’re going to a lot of trouble to work around problems with that particular plugin

1 Like
4

The problem is that all available organ plugins do sound slightly different, so if you want the specific VB3 sound, you have to use this plugin. There was a long discussion about VB3 against other plugins before in this community.

As being a big fan of the VB3, but using Blue3 because of the issues with VB3, I thank you for your workaround and will try. :+1:

1 Like
5

I originally tried this method back when I first was using VB3 in gig performer but could never get it to work reliably. Not sure what the hang up was. Since I tried it when I was only first getting accustomed to Gig Performer, there’s a chance I didn’t have it set up correctly. But if this method works without hiccup for you, this is definitely a simpler way.

6

I have considered it yes. VB3 does have a really fantastic sound and is much lighter on CPU than Blue3 or omnisphere. Furthermore, the presets are more “performance-ready” than most of the other organ plugs I’ve tried. For me, it’s worth it to use the workarounds. But I understand why some might disagree.

1 Like
7

Agree that VB3 is much more “performance ready”, but I had crashes down to desktop from time to time and so I’m using Blue3 and PSP L’otary on stage instead.

But I will definitly try your workaround and want to thank you a lot!

1 Like
8

No worries! Let me know if it works out for you

9

Hey Josh, thanks for sharing your solution. I wanted to add some observations that might be helpful to the many keyboard players who strive to recreate the powerful impact of a B3 through a Leslie, properly miced up and screaming and growling as only a Hammond and Leslie can do, through a concert PA system, and aren’t willing to settle for a weaker sound just because it might be easier to set up.

Having owned and moved numerous Hammonds and Leslies for many years, I was quite happy with the B3 emulation I used to use in MainStage before switching to Gig Performer a year ago. After trying a number of replacement candidates, I decided on the GSI VB3 for its rich, powerful sound and tweakability. Having decades of experience with the real thing, I was very picky about what I could get from a plugin, and to my ears, the VB3 beats all the rest.

But the organ sound is only half of the equation. The Leslie emulation is every bit as crucial to the full experience. The VB3 Leslie emulation is good, though I don’t think as real as the Logic/MainStage emulation. I just discovered a plugin in that I think, like the VB3, beats the rest for a true-to-life B3/Leslie sound. It’s apparently been around a while, but I was never aware of it until a few weeks ago, and it’s now part of my Gig Performer organ setup. It’s from a plugin company based in Prague, and it’s called the MeldaProduction MVintageRotary. They don’t pay me, this is strictly a recommendation based on sound quality. Here’s the link:

Everybody’s ears are different, and your mileage may vary, but for me the GSI VB3 with the Leslie emulation switched off, through the MVintageRotary is as real as it gets today.

Thanks again for your preset loading solution, very helpful.

3 Likes
10

Wow… thanks for the detailed setup. I love this plugin but ran into crashes attempting to use Program Change messages. These crashes would intermittently occur on loading a gig. If a gig loaded successfully then no crashes would occur.
I solved the problem by getting rid of using Program Change messages and creating more rackspaces. I too noted the issue where some settings are global across multiple instances.
I’m going to experiment with your instructions. Will there be a new version of the VB3-II that addresses these issues?

11

Did you already try this one?

12

I think ik one is by far the best to my ears

1 Like
13

Melda makes some awesome plugins in general! Completely agree on the sound quality of VB3. Unfortunately I’ve never owned/gigged with a real electric organ but I am a snob when it comes to emulations of real instruments, particularly organ. I’ll try this one out in addition to the IK suggestion.

I was running into the same crashes on load issue until I started using this method. For whatever reason, it’s much more stable for me. Hope it works out for you too. I also originally tried just making multiple rackspaces with whatever presets I wanted in VB3 but they would load with the proper preset only about half the time. Either way, the way I’m doing things now (though very time consuming to set up properly) is much more stable and reliable for me in that I know as soon as I switch to a given song part, the organ is loading up with the exact preset I want. Also gives me a little more flexibility and efficiency in being able to change presets in a single rackspace with one instance of VB3 running.

From what I understand and if memory serves when I looked it up, VB3-II is programmed in such a way that “solving the issue” would involve a major overhaul of the plugin itself and I don’t think the developer plans on doing that. I put “solving” in quotations since depending on who you ask, the preset switching functionality is designed in this way intentionally to cater to live performers. But for whatever reason it doesn’t play nice with Gig Performer all the time. For me it’s a moot point though, because in my opinion, the original VB3 is a little more user-friendly in its GUI and requires a lot less time to get awesome sounds since all the presets are more performance-ready to my ears. Again, just trying to recall what I read when researching this months ago so I could be way off base in my recollection.

14

Hi David-san. Yes, the Melda MVintage Rotary is my Leslie emulation of choice, and each instance of GSI VB3 goes through it in my setup. I haven’t tried the IK T-RackS Leslie, but I’ll check it out. I did try the PSP Lotary, and it doesn’t measure up in terms of matching the real thing to my ears. I had high hopes for it as my experience with PSP is that they make top quality plugins.

I took a screen shot of the wiring on one of my GSI VB3 racks to clarify how I have the MVintage Rotary setup. From the top down, the T6 - 88 MIDI in block is an omni in block so that I can play the organ from either keyboard. My lower keyboard is an 88 key, which allows me to take advantage of the VB3 capability for key triggered drawbar set changes, like the reverse color keys at the left end of the keyboards on an actual Hammond. The octave of keys below the range of the organ calls up those preset changes, very handy, and authentic to the actual Hammond experience. Next is a MIDI filter to filter out sustain pedal events from going to the VB3, on which the Leslie emulation is shut off inside the plugin, as I don’t want it changing speed and conflicting with the Melda. Next to the VB3 is another MIDI input block in which everything is filtered out except sustain messages. Thats plugged into the Melda to control speed switching. I have the MIDI filter and the sustain control block open in the screen shot just for clarity. They’re not normally visible.

Here’s a screenshot of that rackspace wiring diagram:

Screen Shot 2022-07-06 at 8.42.44 AM
Screen Shot 2022-07-06 at 8.42.44 AM921×1014 248 KB

While it has nothing to do with the organ setup and Leslie control, I’ll mention in passing regarding the final block in the chain, that every one of my sound sources within GP goes through a console emulation, of which I have many, and choose them according to how I want to match their sonic footprint with the sound source I’m processing in each rackspace. From there, each rackspace goes to the same global rackspace which acts as a final mixbuss processing chain. Here’s a screenshot of that global rackspace processing chain:

Screen Shot 2022-07-06 at 8.58.22 AM

The first block, True Iron, is an excellent emulation of various tubes, transformers, etc., from classic analog gear, for some weight and color. Next is a very versatile processor which I have setup for some stereo width and light dynamics control. That all goes into a remarkable compressor made by DMG Audio, which gives me presence, thickness and further dynamic control. In my experience, you get much better results from serial compression, using a couple of compressors with moderate settings instead of trying to squash things into submission with one compressor with heavy handed settings. It also gives you the option to, for instance, start with a fast VCA or FET style compressor to catch transient peaks, followed by a slower, optical style compressor for warmth and broader overall level control.

Hope this all helps. I understand some of this might be elementary for some, boggling for others. Use what’s appropriate for you, ignore the rest!

2 Likes
15

I would prefer to add one Rig Manager defined MIDI in block per keyboard to avoid surprises when extending your keyboard rig. And you can also filter out any MIDI message from the MIDI in blocks (like you did with a MIDI filter.

Regarding the audio routing from the local rackspace to the global rackspace, that’s also what I do for similar reasons than yours. :wink:

1 Like
16

Agreed. The OMNI block is really only intended for getting started. As soon as users are comfortable with the basic workings of GP, we encourage them to start using individual device specific MIDI In blocks and the rig manager if there is ANY possibility that keyboards might change.

17

Hi David. You and David-san are both correct. I should have clarified that for the majority of my rackspaces, I do in fact have two separate keyboards defined, an upper and a lower with discrete connections that don’t overlap, using two separate dedicated MIDI in blocks. I do also prefer to have a few that I can play from either keyboard using the omni in, depending simply on the physical variable of whether I’m standing or sitting in any one moment. The beautiful versatility you’ve built into GP makes such options easy to access.

Of course, you’re also right about simply using the filtering options in the MIDI inblock instead of a separate filter. I honestly don’t remember my thought process in initially setting up the Leslie control that way, but I’ll go back and use that capability to eliminate the unnecessary separate filter.

Thanks for pointing that out!

18

But you can do the same thing by simply having two device-specific MIDI In blocks connected to the same synths. And by creating those two devices and saving as a favorite you can trivially insert the two blocks at the same time when you need them.

19

I agree.
Using OMNI in MIDI block is very scary to me. Adding any new controller to your rig, e.g. a control surface, can add note messages directly sent to your plugin instrument. And if you don’t block other MIDI controls, any unwanted CC# can reach your plugin, e.g. any CC#7 0 from a forgotten volume pedal, means no more sound :cold_face: Rather adding 10 different MIDI in blocks to the same plugin than 1 OMNI in block even if it should work too.

20

Point taken. I’ll go back and put two device specific MIDI inblocks in each rackspace, both connected to the sound source, and ditch the omni in block in the few instances where I used it. I can especially see the advantage to that approach when considering swapping out keyboards and other controllers in future setups.

Thanks again to both of you!