Switching plugin presets on variation load

Scripting with Gig Performer
1

Hi friends, brand new user here. In fact, I’m still on the trial version, but I’m going to buy the full version when I have the money. In the meantime, I’m doing my best to learn how this awesome bit of software works.

I found the rackspace file created by @Ipkz inspired by @schamass for Neural DSP’s Archetype: Gojira X and it is so much better than anything I tried to create (although I edited it to load the VST2 version of the plugin because for some reason the VST3 consistently takes 10 minutes to load, give or take 15 seconds or so). My panels look like a two-year-old’s crayon drawings at best, by comparison. I’m going to try to adapt it to Rabea X, as well, and some of the others that I have, but I’m expecting to get pretty stuck pretty quick.

At any rate, one bit of extra functionality I’d like to add is to load presets on variation switch (i.e. Variation X will load preset PX and Variation Y will load preset PY, etc.). I’ve done some digging here on the forum and from what I understand, it’s not possible to grab the presets from directly inside the plugin itself. If I understand the scripting manual and functions list correctly, however, it is possible to select plugin block presets, so I though why not just map 1:1 the internal presets to the plugin presets?

Now, the code I have is as follows (and bear with my, my programming days are long over, so I don’t pick this up quite as well as I used to):

var GojiraX : PluginBlock

On variation (oldVariation : integer, newVariation : integer)
    Select
        newVariation == 0 do
            SelectPreset(GojiraX, 0)
        newVariation == 1 do
            SelectPreset(GojiraX, 1)
    End
End

It doesn’t seem to really work, though, and I don’t understand enough about the functions to figure out why.

  • It doesn’t make sense to me that variations are integer types. How does that work?
  • Is each variation just assigned a number in the background?
  • How do I know which integer is assigned to which variation?
  • I really have the exact same questions about the SelectPreset()function.
  • When calling On variation(), how do I know what the old variation is and what the new variation is? Frankly, I don’t really care what the old variation is, just what the new one is. Unless I’m perhaps missing an important piece of information that means I should care what the new variation is?

There’s definitely things I’m not understanding here.

What do I need to know to make this work?

2

You don’t mention your environment (OS, hardware, audio interface, etc) so hard to tell what’s going on. If you’re telling us that a single VST3 is taking 10 minutes to load, then there’s something terribly wrong with your configuration.

What type are you expecting? A rackspace consists of N variations using zero offsets so if you have 6 variations, then they would be numbered 0 .. 5 starting from the first one. Those are integer values.

The first one is 0, the next one is 1, the next one is 2, etc

I don’t understand this question. The parameters to the On Variation callback represent the old and new respectively variations indices. If you want to know the name of a variation then use the GetVariationName system function which takes the index as a parameter and returns the name of the variation

3

The SelectPreset function will only work if the plugin exposes its inbuilt presets to the host (Gig Performer). This behaviour can be different between the plugin formats, so there’s a good chance that the VST2 plugin is not exposing the presets to GP and therefore why the script doesn’t work.

While you have the plugin window open, navigate to the GP plugin menu in the upper right corner, and see if the menu shows the plugin presets. Compare that to the VST3 version.

4

You don’t mention your environment (OS, hardware, audio interface, etc) so hard to tell what’s going on. If you’re telling us that a single VST3 is taking 10 minutes to load, then there’s something terribly wrong with your configuration.

I’ve got a ticket going with Neural DSP on this as the issue exists outside Gig Performer, too. I’m on Windows 10 with an Intel i7-5820k, an MSI GTX1080, and 16GBs of RAM at 2133 MHz. My interface is a Scarlett 18i20. I’m not really sure what that has to do with it, though.

The weird thing is that yes, a single VST3, Archetype Gojira X, takes 10 minutes to load on Gig Performer (and LiveProfessor). The VST3 loads just fine in Reaper and in Cantabile. The standalone work just fine. The VST3 of Archetype Rabea X works fine in all environments. So does the VST. It is specifically the VST3 version of specifically Gojira X that exhibits this behavior in specifically VST hosts, minus Cantabile. It’s very weird.

As for configuration, I just said this in my last email on the NDSP support ticket, but I downloaded the installers for the plugins and the VST hosts and ran them. The only “configuration” I’ve done is that I have a specific folder that I store my plugins in, but I have also tested it by installing them in the default locations. I’ve done this on three different machines, two of them being entirely fresh Windows installs. They all exhibit the same behavior. So I don’t really know what to say…

What type are you expecting? A rackspace consists of N variations using zero offsets so if you have 6 variations, then they would be numbered 0 .. 5 starting from the first one. Those are integer values.

I was expecting them to be called by their names, but your explanation makes sense.

I don’t understand this question. The parameters to the On Variation callback represent the old and new respectively variations indices. If you want to know the name of a variation then use the GetVariationName system function which takes the index as a parameter and returns the name of the variation

My goal here was to write this script to be agnostic of the variation that came before it. Based on my understanding, the variation() call requires the preceding variation to be known. Or am I misunderstanding this?

5

The code example you shared above has the callback for a variation change:

On variation (oldVariation : integer, newVariation : integer)

The oldVariation variable provides you the variation index of the one you came from.

If you want the name of the prior variation, you could use the function mentioned by @dhj

GetVariationName(oldVariation)

6

It can be…just ignore the parameter that informs you of the variation that was previously active

7

Pivoted to doing essentially the same thing with my Rabea X rackspace, and this is what I’ve got:

var RabeaX : PluginBlock
On variation (oldVariation : integer, newVariation : integer)

    
    Select
        newVariation == 0 do
            LoadGPPreset (RabeaX, "Rabea Angry Brit")
        newVariation == 1 do
            LoadGPPreset (RabeaX, "LeoFrogRhythm Down 2")
        newVariation == 2 do
            LoadGPPreset (RabeaX, "LeoFrogRhythm")
    End   
End

I’m just using a couple default patches that I named the GPPresets identically to (except for the transposed patch, of course).

The issue I’m having is that sometimes when I switch to the LeoFrogRhythm Down 2 variation from the LeoFrogRhythm variation, it takes loads the amp and sometimes some of the pre- and post-fx from the Angry Brit variation. There’s also a slight delay/dropout while it switches. Is this some bug in my code, or is it likely another issue?

8

This is normal. A GP preset is loading the full plugin state and these sort of delays/interruptions of the audio is what happens. The extent of the delay is down to the plugin, not GP.

If you want to seamlessly change the transpose, that’s what widgets and the normal use of variations is for. If you want seamless transition between very different presets, that’s what rackspaces are for.

9

If you want to leverage instant glitch free switching then you need to use the GP paradigm which means using different rackspaces for different sounds and using variations to just tweak a couple of parameters. So technically it’s a design bug in your code.

As @rank13 correctly pointed out, while the LoadGPPreset feature can be very useful if one does NOT need instant switching, most plugins themselves generally cannot be switched instantly, whether you use GP’s User Preset or even just program changes for plugins that support that. Depending on what the plugin needs to do it, it can cause a little glitch, or (if new samples have to be loaded), it could be dead for many seconds. You also run the risk of some plugins not properly handling incoming MIDI messages while they are changing their state (so test very carefully)

That is why GP generally uses a model where everything is loaded in advance.

10

I’ll be a litle more direct than the others… I think you’re trying to use Variations where you should be using Rackspaces.

In five or so years of using GP, for keyboards, guitar, and drums, I have never once used VST presets, and almost never use scripting.

What you really want to do is think of one Rackspace as one “sound”.

Variations are good for things like instantly turning an effect or two on or off, or changing a couple parameters. Think of them as relatively minor tweaks to your sound.

If you need a different preset within the Neural DSP VST just duplicate the rackspace, then load the different VST preset in the copied rackspace.

While scripting is a great feature I would highly recommend getting to know how GP works without scripting. I’d guess 95% of users never touch scripting and don’t need to. As you’re using it here, I think you are making things more complicated and less functional for no particular reason.

11

What you, @rank13, and @dhj have all said regarding the delay between switching presets makes sense, and I honestly kinda already guessed at what those two said. I wanted confirmation or to see if there was an adjustment I could make to my code to make it better. But fair enough.

Now, I realize what you say about the true use of rackspaces and variations. While I’m currently doing all of my configuration on my desktop, I plan to be running this on a laptop, and I’m not expecting it to be a new or very powerful laptop, either, so I’m trying to plan for not having a lot of headroom to work with, to work with the limited resources I’ve got. Therefore I was hoping to be able to limit the number of these heavier-weight plugins to one so that the laptop will not struggle too much.

12

Why do you think that having one of those in each of multiple rackspaces will be a problem?

13

Because each rackspace has its own instance. If I have seven different rackspaces, each with an instances, that’s going to take a lot longer to load and consume a lot of processing overhead than if I just had one rackspace with one instance that changed presets on different variations.

14

What’s the hurry - it happens once, at startup

What processing overhead? The audio threads for plugins in non-active rackspaces are automatically bypassed. Only one is active in general, with a second possibly active for up to a second or two depending on how you configure the length of your audio tails

Also understand that the CODE section of a plugin is shared - it is not loaded into physical RAM multiple times.

15

Oh! I did not know this! That totally changes my perspective. Thank you!