Add a button (say the LED button) to a rackspace. Call it OneStateButton
You’ll get a single callback whenever you push the button. If you don’t care about the state, then just ignore that the LED goes on or just set its value back to 0 inside a script. See the following
var
OneStateButton : Widget
// Called when a widget value changes
On WidgetValueChange(newValue : double) from OneStateButton
SetWidgetValue(OneStateButton, 0.0)
Print(“Bang”)
End
@JellyDude
Types are still in flux — in the next update, the type “PluginBlock” will be used to refer to a typical synth instrument or effect block.
The MidiInBlock is an extended PluginBlock due to it having various callbacks as well as the ability to send out MIDI events.
The keyword “Block” will only be available as a formal parameter used to represent the lowest common denominator of blocks.
It will be a while before there’s serious stability to the GPScript language definition (you guys are the first to have even seen it) as I’m still adjusting it based on the feedback I’m seeing from everyone.
The discovery process (such as the wonderful code completion system that Nebojsa wrote) and interaction in these forums is really the only way to get up to speed with GPScript at this time.
Welcome to being part of an early group using a brand new programming language!
I’ve noticed that if you load a plugin (say FM8) and select a preset (say 303) and save the gig file, exit GP, then restart GP the plugin is loaded with the saved preset 303. So in the Gig file the state of the plugin is saved and retrieved.
For a variation, I’m assuming only the state of the widgets are saved along with triggers when the variation is loaded (as discussed in your Rackspaces vs Program Changes blog).
Is it possible to have an option to save the state of a plugin with a variation? It understand it drives the logic backwards :- rather than the widgets driving the plugin, the plugin will drive the widgets. Also there may be latency issues that the variations are mitigating against.
Just a thought - would get around the program change versus plugin preset hassle.
Unfortunately, (and something that was unexpected to us when we started this project), the quality of implementation and design choices in plugins varies widely from one plugin to another with some of them being downright shitty!
Some plugins just respond automatically to program changes, some ignore program changes completely, and some require program change support to be explicitly turned on.
Same goes for “presets”. For example, my otherwise favorite hammond organ plugin, Blue3, doesn’t expose its internal presets as host accessible unless you save them to a MIDI folder!
Sometimes program changes are the same as presets, sometimes they’re not.
Plugins only respond to program changes if they come in via MIDI, which is why there’s no option to send a program change directly to a synth plugin, you have to connect a MIDI In Block to the synth plugin block and then send program changes through the MIDI In block, which by the way is why our datatype MidiInBlock is not quite the same as Block or PluginBlock, it has these extra capabilities.
Sadly, we (and you) are at the mercy of the plugin developers for this stuff. If they don’t expose it, we can’t get at it.
I have tried sending the program change message, but most of my plugins didn’t respond. I’ll need to do a combination of program change messages and setting presets.
That’s called a rackspace 
Is it possible to have an option to save the state of a plugin with a variation
We have in fact considered the notion of storing all “deviations” from a saved state, for example imagine if hidden widgets were created each time a plugin parameter is changed.
However, we don’t know how this would affect latency if you changed a lot of parameters and we don’t want Gig Performer to get an unnecessary bad rap as being slow when in fact the simple way to solve this problem is simply to duplicate a rackspace and then change your preset.
That’s called a rackspace
Yeah - Worst case I’ll create several rackspaces containing the same plugin with different saved states - but unless you’re doing a sweet Singleton pattern which I’m guessing you’re not that will take up valuable memory and time to re-load the plugins - far easier to modify the existing plugin (if we can). I’ll sort something.
Ahhh, thanks David. I didn’t know about this special Program List in FM8. Never considered to use FM8 live. Great article. In Absynth it works the same - cool.
David, one different thing: You recently decided that we don’t need to activate scripting for Widgets anymore. It’s now enough to give them a name. Wouldn’t the same thing make sense for Blocks too? Since two Blocks can’t have the same name, why don’t you just expose all Blocks to scripting that have been given a name?
Why is that a worst case? It sounds like you’re completely missing the point of using multiple rackspaces and possibly the benefit of predictive loading if you actually are running out of RAM without it. You also lose the ability to leverage Patch Persist. Loading a plugin twice (for example) does not mean using double the amount of RAM. If you load Lounge Liazard or Blue3 (say) into 20 rackspaces you will not use 20 times as much RAM as just loading them once.
It sounds to me that you’re engaging in premature optimization. I would encourage you not to try to workaround what Gig Performer (and the OS for that matter) is doing. This is why I wrote the blog article about rackspaces va program changes (presets) in the first place. Presets are here if you’re desperate but generally I would just use presets to save different sounds that you need to make it easier to get a particular sound when you make a new rackspace,
By the way, the Singleton pattern is rarely a good idea. See for example
https://blogs.msdn.microsoft.com/scottdensmore/2004/05/25/why-singletons-are-evil/
I use both FM8 and Absynth live all the time but I never use presets. I just load the sounds I need into new rackspaces .
Ahhh, thanks David. I didn’t know about this special Program List in FM8. Never considered to use FM8 live. Great article. In Absynth it works the same – cool.
OK, sending Program Changes to FM8 works fine now. But I couldn’t manage to send a program change with the value 0 so I can’t select FM8’s first program.
var programChangeMsg : programChangeMessage
programChangeMsg = MakeProgramChangeMessage(0)
SendNow(MidiIn, programChangeMsg)
The Midi Monitor says that MakeProgramChangeMessage(0) and MakeProgramChangeMessage(1) produce the same PC message (value = 1). Is it a bug or did I do something wrong? I tried “Use zero-based program change numbers” but it had no effect on the scripting command…
Maybe it’s me, but if I have a plugin loaded (say electric piano plugin with a Rhodes sound) and the singer calls out a song that requires a whirli sound then rather than selecting a new rackspace and waiting for the same plugin to re-load (ignoring the difficulties on touch screens to select the rack), I could quickly select the current plugin’s whirli in-built preset via a button widget or knob. Seems to me as the most efficient use of resources and time - but if it can’t be done then it can’t be done.
@Lukas That’s what’s known as a bug! Good catch, I’ve just fixed it, will be in the next update. I was constraining Program change values between 1 and 128 instead of 0 and 127
OK, sending Program Changes to FM8 works fine now. But I couldn’t manage to send a program change with the value 0 so I can’t select FM8’s first program.
Unless you’re using predictive loading, switching from one rackspace to another is instantaneous. The plugins are preloaded already.
rather than selecting a new rackspace and waiting for the same plugin to re-load
Why are you concerned about resources? Are you running out of RAM?
Seems to me as the most efficient use of resources and time
Maybe it’s me, but if I have a plugin loaded (say electric piano plugin with a Rhodes sound) and the singer calls out a song that requires a whirli sound then rather than selecting a new rackspace and waiting for the same plugin to re-load (ignoring the difficulties on touch screens to select the rack), I could quickly select the current plugin’s whirli in-built preset via a button widget or knob. Seems to me as the most efficient use of resources and time – but if it can’t be done then it can’t be done.
Gig Performer is built for live use and has ability to switch between your sounds instantly while NOT cutting of the previous sound abruptly and unnaturally. It also supports patch persist when switching rackspaces so you can have several sounds layers if needed.
There are many disadvantages of sending PC messages directly into plugins or selecting plugin presets using widgets or GPScript.
Here is a list of some that you should expect::
<li>Plugins that can switch quickly usually don't use a lot of ram as they are not loading samples. Doing this on a sample based plugin could do anything from crashing your GP to having you wait for a long time until plugin loads everything it needs to play your sound.</li>
<li>Stability is compromised as some plugins are simply not designed to work with live environment and quick switching</li>
<li>Patch persist functionality in GP will not work with this approach</li>
<li>Sound that you played before switching will be abruptly cut off.</li>
<li>In some cases you may hear strange, loud artefacts while the plugin is switching parameters. (happens with several guitar processing plugins)</li>
In other words - I STRONGLY recommend that you do not switch presets directly unless you have a very good reason to.
Ask yourself why are you trying to do that and if the answer is memory saving - please understand that plugins using samples use a lot of ram and those will not allow you to switch instantly between patches anyway. Try GP’s patch persist feature instead.
David, one different thing: You recently decided that we don’t need to activate scripting for Widgets anymore. It’s now enough to give them a name. Wouldn’t the same thing make sense for Blocks too? Since two Blocks can’t have the same name, why don’t you just expose all Blocks to scripting that have been given a name?
So I’m on a gig playing a Joey Defrancesco style organ piece using Blue3 or VB3 and in order to change from internal presets “Late Night” to “Warm Comp” to etc,etc I have to change racks. So I create 6-8 rackspaces of the presets I commonly use. Then add in a number of presets I may be interested in for my electric keys / rhodes / pianos / strings and I’m now starting to get a lot of rackspaces.
It is not about memory but efficiently changing an internal preset in real-time. I can create knobs and sliders that change plugin internal parameters in real-time, I just can’t seem to do the same with a preset.
When you say that you “have to change racks” I assume you mean that you switch you rackspace right? If so - that’s absolutely right. Weather you are switching a rackspace, variation or switching a preset with a plugin - you have to push something.
Switching to a different rackspace is the most efficient way of switching to a new sound. If you switch a preset within the plugin itself - it is MUCH less efficient and in some cases could produce undesirable results.
For example - one of my amp simulator plugins produces sort of a “squeak” whenever I switch to a different plugin preset internally and playing (perfectly normal if you are plying a guitar for example).
Placing my different sounds to different rackspaces not only gets rid of that problem, but also allows the sound to naturally switch over, not get abruptly cut off. There are several more benefits of placing different sounds into different rackspaces - I’m just trying to learn what drawbacks are you finding (excluding the memory usage of course).
So I am not sure I understand you comment about “efficiently changing” things. Could you please provide more details about what concerns do you have exactly - I must be missing something obvious here 
A comment from a long time user of MainStage (not anymore):
Because MainStage loads all plugins into memory I had to think about memory usage.
So I used alias channels and switching presets via Midi commands assigned to mappings in the patches.
I am so happy with GigPerformer and the concept of rackspaces (special predictive load is a life saver!),
I do not have to take care of Alias channels and all restrictions in using them.
I would never switch presets via Midi Message, just use different rackspaces or variations (you should check out the midi filter NOTE ON).
This way your setup stays simple, reliable and super flexible.
And when you use a Mac or PC with SSD Drives and 16GB of memory you are save on stage, believe me.