I am trying to find the most efficient way to change settings on my plugins. For mid song tweaking, I imagine only using a couple of widgets. However, compared to another song, the base settings for the plugin might vary quite a bit.
For simplicity, lets say a plugin has 8 parameters, and I want to change them all between songs, but during the song I always tweak the same two parameters. So, I want to use only two widgets, right?
I am looking for a way to load these changes when changing songs. Do the rackspaces remember what preset a plugin is set at? Will I need scripting? How can I avoid cluttering the rackpanels with a lot of widgets?
You will only need widgets for the parameters you want to change.
If you use Panels view, you use Variations to change the parameters of the plugins (widgets) that are in the Wiring View. You use a new Rackspace when you want to change which plugins are in the wiring view.
The state of the plugins is remembered for each rackspace and variation.
If you use Setlists view, you create songs and song parts, which you then associate with your rackspaces/variations. Each one gets remembered so that when you load a song and song part, the proper rackspace/variation is loaded also.
This reply is a step in the right direction. Hiding 6 widgets would be an option if I was only using 1 or 2 plugins. The thing is that I am building a chain of plugins for my guitar sound, and I will at least end up with 8-10 plugins. Then, hiding 6 widgets for each of these 8-10 plugins would still be a lot of widgets to hide.
So I understand correctly: a rackspace will not remember the state of the parameters if there are no widget assigned to it?
I have no issue using the GP Presets. In fact it sort of works as a way of storing favourites. Could someone point me to a script allowing for this? Preferrably as simple as possible, so I can start learning about scripts as well.
No… a rackspace does! It just sores the state of the whole plugin - so to say as “raw data” (it also doesn’t care of an underlying preset name of the plugin).
But rackspace variations only store/recall the state of the widgets that are used on a rackspace’s panel. So you could use them to have “variations” of a given rackspace, i.e. to switch a reverb on/of, or to adjust the amount of overdrive… such little things.
Of course you could also mirror each parameter of a plugin to its own widget, which would make it possible to have complete diffrent sounds to be called as rackspace variation… but to be honest, this is mostly a corner case, and the downside is: Many, many widgets to take care of!
A rackspace stores the state of a plugin for the whole rackspace and all its variations.
If you want to change single parameters within the variations of this rackspace you have to add widgets and set them in each variation to the desired values.
You don’t need to MIDI map these widgets. Just assign them to plugin parameters. They just need to be there to ‘save’ the changed parameters between variations.
An, as said before, you could also hide them, if you only set them up once.
Just to clarify, a variation is a subcomponent of a rackspace. Every rackspace has at least on variation. Variations of rackspaces allow you to change settings by using “widgets”. The widgets can be assigned to (virtually?) any parameter in GP and (via Midi learn, etc.) many/most parameters within the plugins themselves.
You can also save variation’s widget settings in a particular song part saving a “snapshot” (little window upper right). This sort of saves a “variation of the variation” used in a particular song part (I use this all time time to try to optimize relative volumes of plugins, song parts, and songs).
Some common parameters you can control using widgets are volumes (in a mixer), transpose changes, keyrange for splits, etc. But, really almost everything.
So, when you pull up the first rackspace variation, it will recall the “last saved state” of the plugin,
Using widgets, you can either control the widget mid song or you can change song parts (or variations themselves) so the widget settings will update (either by changing variations assigned to different song parts or if you just save “snapshot” of a new widget setting in the song part.)
Are you re-opening the plugin in each rackspace? The current opened rackspace is only for that rackspace. When opening another rackspace with that same plugin, you must open the plugin within that rackspace to see it’s settings.
I am trying to remember, if you go to a rackspace and tweak plugins in the rackspace and then you leave and go back to the rackspace, does it revert back to the saved setting or the last (unsaved) setting.
If it is the latter, you would need to either save the Gig File or (I think) save the rackspace (the rackspace had to be part of the Gig file before. There are some quirks to saving a rackspace I recall reading about).
Also, I think even if you “save” a particular rackspace, you still need to save the Gig file so it is saved that way in the Gig file.(?)
[Warning, I might have some wrong info here. So proceed with caution].
A plugin is only active (using CPU) in the active rackspace (and the Global Rackspace, which is always active). This was (wisely) engineered this way to control CPU use.
Ram is different. In order or allow seamless changes between rackpsace (unless Predictive Loading is used) all samples needed for moving seamlessly between rackspaces are loaded in the Gig File (or course, if ram streams from disc or other ram conserving strategies are used, ram use is mitigated).
