Right, let’s try and get GP to do something it isn’t designed to do
So, my use case is using GP for my guitar rig - everything run through it. Within local rackspaces are the ‘gain’ components (drive pedals, amp, IR) and in the global rackspace is all the wet FX. Reason for this setup is, perhaps not intuitively, for CPU saving - allows full and proper delay/verb spillover for minimal dynamic CPU hit (will explain that later if needs be, but isn’t important to the question).
Each rackspace is a combination of amp and drive pedals. I do then have variations with common combinations of FX (global controlled from the local rack panel and all linked to a MIDI controller).
I then use Songs/SongParts as normal. So far so normal use.
What I want to do however, is have available a small number (2-4) ‘presets’ for some or all the wet FX where within the local rack panel I can use a set of radio buttons to select those presets that then change the widgets controlling those plugins in the global rackspace.
The things that are going to get brought up are:
Why not use variations for this? Well, there are a lot of wet FX and so doing a full-factorial combination of variations is just infeasible. Also, if I decide I want to change the settings of a preset, I want that to be available to ALL rackspaces and don’t want to have to go through again and change them all
OK, well why not use the already built in GP Preset functionality? This, of course, was my first point of call, but the issue with this is that the recall of a preset ‘triggers’ every parameter in the plugin even if the value doesn’t change. For the verb and delay plugins I use, this has the effect of cutting the reverb/delay tail and it sounds bad. See also other issues DHJ has raised in the past of this not being instantaneous compared to widget changes, etc.
So what am I looking for - ideally a way to store a set of presets of WIDGET settings that on selection of a radio button in a local rackspace those settings are applied to widgets in the global rackspace.
I have started to have a play with the LoadStringFromFile() GP Script function and I think I can get that to work, but haven’t quite figured it out - any help appreciated there! It also feels like this is going in to extension territory? Which is fine and I wanted to jump in at some point. Really just wanted to check that I hadn’t missed some obvious way of doing this.
I would first have to ask if you have tested running the wet effects in your local rackspaces VS your global rackspace. Given the plugins would only be active in the local rackspace, there should no difference in CPU usage.
That being said, one approach you could take is to have multiple instances of the global plugins in the global rackspace, then use widgets from the local rackspace tied to the global rackspace to enable/disable the effects plugins so that you are only routing the ones you want in a given situation. This same approach could be applied to the local rackspace directly if you hosted your wet effects there.
So, what I found is actually that the opposite is true, for a given value of CPU usage that is.
Adding only the local plugins you need to a rackspace absolutely gives the lowest ‘static’ CPU usage - that is just fact. However, when switching rackspaces with trails active both the old and new rackspaces are loaded and you get the CPU usage of BOTH (it’s not quite double) in a spike. A CPU usage, for me, of <30% sees no issues with crackles etc at 16 samples, 44k. So a rackspace set up like this might have a CPU usage of 20%, but that would jump to near 40% on switching until the tails die away.
Instead, adding plugins to the global rackspace might bump the static CPU up to just below 30%, but the plugins with reverb/delay tails are in Global and so there is only a ‘dynamic’ CPU spike of 1-2% on switching which is totally manageable.
Also, this approach would still need a ‘full-factorial’ type approach resulting in an enormous amount of racksapces.
I’m actually doing this already…… as mentioned, for the delays/verbs there are some parameters (mainly modes, e.g. BBD delay, Tape delay, etc) that when switched cut tails. As such I have multiple delay and verb plugins, each with a ‘mode’ I want to use. What I want to do is for each of those have, for example, a bright preset, dark present, wibbly-wobbly mod preset, etc.
You can control global rackspace widgets from a local rackspace using global parameters. The way these are implemented is very confusing to me so I can never for the life of me remember how they work, so I made a megaton of scripts to sync local and global rackspace widgets, but from my discussions about the topic maybe it’s confusing only to me. There’s also a nice blog post that explains how it works.
I used OSC and scripts for syncing, but that was mostly because I needed sync to be bidirectional.
If I understand what you want to achieve correctly, you may have a much easier solution using the built in functionality. So instead of global variations/snapshots/presets/whatever, you have regular racks where you store widget states normally, they’ll just update global widgets instead of doing something in the “local” rackspace, if that makes sense.
