05 Dec Questions about rackspaces and variations
Tech note #1
The goal of this article is to simply explain rackspaces and variations for users who are already familiar with the basics of Gig Performer.
What exactly is a rackspace?
A rackspace is the container for a collection of interconnected plugins representing how audio or MIDI flow from your audio and/or MIDI inputs to various plugins and ultimately out through an audio interface. The front panels of a rackspace are where you can optionally insert widgets (knobs, buttons, sliders, etc) to control parameters of the plugins in that rackspace. The basic state of the plugin is tied to a rackspace.
But….by itself, a rackspace can’t actually do anything. In fact it doesn’t even exist by itself. There will always be at least one variation attached to each rackspace.
So what is a variation?
When you create a new rackspace a variation always is created and associated with that rackspace. There must always be at least one variation associated with (think of it as owned by) a rackspace, i.e, you cannot remove the last variation! We call that variation the default variation.
Is a variation the same as a preset?
You can think of a variation as a preset but we use the term “variation” because, well, things (plugin parameters, for example) can vary although if you don’t have any widgets on the panel, they won’t!
So how do you use a rackspace?
To use a rackspace, you select one of the variations associated with that rackspace. That is why program changes are associated with variations and not with rackspaces.
What do program change messages do?
When you use program change numbers to switch sounds (e.g., from piano to organ or to a layer of piano/strings or to split your keyboard into multiple areas each controlling different sounds) you are selecting some variation and the rackspace that is associated with that variation is activated (if it’s not already the active rackspace)
What makes one variation different from another?
Ah – this is where the fun starts. The answer is widgets! So let’s backtrack for a moment and consider one of your plugins, any one of them, it doesn’t really matter. You can double-click on any plugin block to open its editor window and then you can adjust individual parameters of that plugin to your taste. When you save the gig file, part of what is stored is the state of each plugin in each rackspace. That means that if you adjusted a filter cutoff value or an echo delay, when you save the gig file and reopen it, the plugin will open with exactly the same values for that filter cutoff or echo delay, etc.
But suppose you want to adjust one or more of those parameters while you are performing in a show. This is where widgets come in. Widgets have three purposes
- They can control a plugin parameter
- They act as intermediaries to your MIDI controllers to insulate plugin control from hardcoded MIDI messages
- They can remember values
That last is what distinguishes individual variations. The same widget can have different values depending on which variation is selected in a particular rackspace. Unless you enable “Ignore variations” for a widget, every time you switch variations, that widget will be reset to the last value that was used by that widget in that variation.
Note that variations have nothing to do with the state of a plugin itself. The state of the plugin, generally meaning the value of every single parameter, is stored with the rackspace, not with individual variations. But after the state of a plugin has been restored (i.e, when the rackspace or gigfile has finished loading), widgets in your individual variations for that rackspace will immediately override the specific parameters with which those widget are associated (mapped). Parameters that are not associated with widgets will not be changed after the plugin state is restored.
To put it succinctly, parameters of plugins can be overridden and be different in different variations simply by mapping widgets to the parameters you want to, well, vary.