How to use radio buttons to recall GP Presets of a plugin and then control those buttons via variations

I’m interested in using radio buttons to recall GP Presets of a plugin and then controling those buttons via variations.

The rotary knob concept requires you go thru presets to get to another one. Fine if you want to manage a big list but I’m thinking I’d use 3-5 presets per plugin… or less… so all I need are a few buttons to manage this.

Can anyone steer me to the proper handing of the LoadGPPreset( “PlugInBlockNam”, “PresetName”) function when that is mapped to a button in a multi instance scenario?

For what it’s worth, the way I’ve done this (for experiments, I never do this live) is to use a script that responds to variations changes and then, depending in the variation, the appropriate preset will be loaded. Then I don’t need to use widgets at all.

I understand, I’ve seen your script, used it as well and it’s basically what I need but I just wanted, for organizational purposes, to make it more of an interface, where buttons A/B/C would recall presets… variations of the same plugin, this way I could govern them by buttons and not just scripted into what variation I was on.

I don’t know the proper way to script this, I’ve seen several examples of using a knob but I don’t want to cycle through options, just push a single button (on my controller too) and get the expected preset loaded.

For what it’s worth…is this something similar to what I did in this Rackspace?

HanonB70 extended.rackspace (462.9 KB)

1 Like

I do kind of the same: When I go to the next (or previous) song in the setlist, using a script I load a GP preset for MDrummer and for a jsfx plugin (the last one only remaps midi notes that trigger MDrummer loops).

This is production. The success rate of this depends highly on whether the plugin(s) are coping well with preset changes.

1 Like

yes, that essentially arrives at the same result I was describing.

not implemented the way I had in mind but does the same thing and avoids having to script all the buttons.


Actually… being able to directly assign a preset loading operation to a button is still preferred.

Is this possible?

The button would then be on or off as a result of a variation, it would not ignore variations, and it would be a radio button, but the button state not the variation itself would be the loader for the plugin preset.

One of the main issues using the select var/part 1, 2, 3 buttons is they wouldn’t work the same in both Panel and Setlist mode. I’d like the recall of the preset to be able to function the same way in either mode.

Yes, this is definitely possible with GP-Script.
I did it with a knob, but the main “mechanics” should be adaptable to buttons as well.
It depends on the particular plugin on how good everything works… so there is no guarantee that it will work flawlessly with the plugin of your choice (which would be…?).

But i also encountered a certain “issue” with changing presets in variations
There seems to be a good chance that it comes to a timing problem/race condition, if you use some more widgets to adjust the general behaviour of a plugin via variations at the same time a preset of that plugin is called.
For example, you have a piano plugin and you stored a preset, which you call per variation (let’s assume that this preset uses some reverb).
In the same rackspace panel you wanted to have a widget to switch ON/OFF that reverb.
So, normally you would make two varaiations of your stored “preset” but in one of them you have the reverb widget switched of, so you could simply activate the correct variation with or without having reverb.
Now comes the caveat:
Since the activated reverb is part of the stored preset, it might overwrite the reverb widget setting again, as soon as it is completely loaded - i guess, the timeline of events would be like this:

  • a variation is called
  • all the panel widgets are set as they were stored for that variation (this happens instantly)
  • the desired plugin’s preset is called
    the plugin prepares all the needed stuff, i.e. samples & parameters (this will neeed some time)
  • if the plugin has finishes preparing the preset, all the parameters are set and
  • all the widgets which use one of those parameters will be (re)set to tha values of the called preset

To avoid this, Gig Performer (or respectively any plugin host) had to have the abilty to determine if a plugin has actually finished “loading” a preset, and only after that happened, refresh the widgets according to the variation settings (Say “wait for the plugin”).
But if i recall it right, this is not supported by plugins (that they tell the host when they are done), but i may be wrong… maybe @dhj can say some more on this…

This all means that any changes you would like to have, have to be made within the preset itself!
…and if you would like to have three diffrent variations of a preset that had to be initially loaded whith a rackspace variation, you would have to store three diffrent presets!
Of course you can use widgets and change parameters on the fly, but everything only after the preset has loaded!

It is going to completely depend on the plugin. We have absolutely no way to determine when a plugin has finished loading. A developer may decide to do all or some loading as a background activity and return early. This wouldn’t matter in a track-based DAW, for example, because the host automation stuff would be stored on tracks and so would not need to update until you start playing the track,

1 Like

Thanks for the answer. :+1:
I think you already mentioned this somewhere else, but wasn’t sure about it anymore.

Thanks @schamass I get the limitations wtih the widget recalls… I think expecting widgets to work in a way that overrides the setting recalled is problematic and I would expect some delay before the widgets become completely useable.

For my use case I am wanting to recall a bunch of presets within Pianoteq which seems to do the recall pretty quickly. I would want the sound recalled exactly as I saved the preset to be and then and only then adjusted by widgets if at all.

So a basic situation.

I just haven’t seen any examples where buttons are used (only a slider or knob) and I am not able to figure out the scripting through trial and error.

Ok… i wanted to make something for Pianoteq anyway (lucky you! :wink:), and a “button selector” for diffrent presets seems not to be the worst idea. :sunglasses:

I think about having 8 buttons on the panel (=8 presets), where a button would try to call a GP-User preset with a name corresponding to the caption of the button widget - that way it would stay quite flexible in use.
Would that be a suitable solution for you?

1 Like

I was thinking about something like this…


So a matrix menu of sorts… If I could get just two buttons working I could expand that idea to fit the larger concept.

These button states would need to work as radio buttons of course.

Hm… i see the purpose, but this would be quite inflexible.
GP-User presets are generally called “by name”…
With the way i planned to do this, the user woulldn’t have to touch the underlying script at all.
All that had to be done is to use the same name for the widget caption and the preset name and everything would work out of the box (at least it should).
If the buttons are labelled 4x A/B/C this wouldn’t be possible and the preset’s names would have to be “hard coded” into the script, and everytime something had to be added/removed, the script had to be changed and re-compiled.
But you could of course use “invisible ink” for the button’s actual captions, which would keep my (yet non existent) script working, and then place text labels of your choice at any place you like. That should be a “workaround”. :wink:

I understand… I was prepared to hard code the names in the script.

The labels A/B/C are arbitrary really… I was just thinking 3 versions of each sound type would be more than enough. But I wasn’t indending on the script being reliant on what the button names were.

I don’t personally want a lot of text in my UI… I would from memory know which Wurli was A, B or C for instance.

What you were planning sounds ‘next-level’ in terms of it’s automation but it would still require the end user follow a naming convention when the presets were saved no?

For my presets I was going down a path like this:




This way I would have 10 possible patches per type that I could (through coding) assign any combination of to the three buttons.

This is all a bit arbitrary of course but having the patches organized like a bank kind of makes sense… would allow it to work with the knob approach too, right?

I don’t plan to use more than say 3 different pianos but if I later just had to have 5, it would be easy to modify the setup to accomodate 5.

Ah… just let me make a first “draft”, then you might see how it works (or doesn’t :smiley: )
I guess, you can adapt it very easily to your own needs - i want to create something which is easily usable for anyone, not just especially for you only (but as i said, you might adapt that very easily). :beers:

1 Like

I think that is a great goal and I am happy to beta-test it… but I’m looking for something basic to start wtih

Alright… this should work:

There was a scripting fault - please download the new and corrected version (V2) of the gig file!

This is a 3x4 button matrix to switch between previously saved GP-Userpresets of a plugin (here Pianoteq from Modartt).
Enter panel EDIT mode and use the same widget caption like the name of GP-Userpreset you want to recall. If the “Customized Caption” of the widget is not “empty” or “” then pressing that button will attempt to load the the GP-Userpreset corresponding to the widget’s caption.
Of course you should have saved some GP-Userpresets to be recalled…

12 button preset select3

The buttons act as radio buttons, so there can only be one active at a time.
The font color of the widgets is set to full transparaent, so that there is no visual distraction by long or cryptic captions.

The 12 widgets can of course be MIDI learned to buttons of your hardware controller.
And you can save a setting as variation, so you can call it via PC from otside of GP.

Everything is done via GP-Script, so if you change the number of buttons or the used plugin, make sure you make the needed changes in the script and in the widget/pluginblock handles!
(And don’t forget to re-compile after you have changed something.

12 button preset select V2.gig (459.0 KB)

This is the script behind the curtain:

pad01, pad02, pad03, pad04, pad05, pad06, pad07, pad08, pad09, pad10, pad11, pad12 : widget
lblPresetName : widget
plugin01 : PluginBlock

padField : widget array = [pad01, pad02, pad03, pad04, pad05, pad06, pad07, pad08, pad09, pad10, pad11, pad12]

index, activePad : integer
    for index = 0; index < Size(padField); index = index +1 Do
        if GetWidgetValue(padField[index]) >0.6 then

// Called when any of several widgets changed
// The widget and index parameters are optional
On WidgetValueChanged(w : Widget, index: integer, pVal : double) from pad01, pad02, pad03, pad04, pad05, pad06, pad07, pad08, pad09, pad10, pad11, pad12
actPresetName : string = ""
    if pVal > 0.6 then
        actPresetName= GetWidgetLabel (w)
        SetWidgetLabel (lblPresetName, actPresetName)
        if not (ToUppercase(actPresetName) == "EMPTY" or actPresetName == "") Then
            LoadGPPreset( plugin01, actPresetName)


Fantastic script @schamass!

Love the way the names of the presets can be entered as the caption of the buttons vs. put into the script. Very user friendly.

Going to do a deeper dive with this tomorrow.


1 Like

@schamass So i’ve enountered an issue with the script or rather the widget setup…

The Send on Radio Button Off should be off not on… I believe this is what was causing plugins presets to not actually load every time for me.

1 Like