Understanding "Variations" ? i have a hard time to grasp it

i have a hard time to grasp how “Variations” exactly work and whats the limits and rules.
maybe i missed spots in the manual. What i´read made it not clear to me.

  1. is a variation only saving parameters thar are comntrolled by widgets ( thats how i understood what i´ve read)
  2. or can i adjust any parameter within a plugin by hand, save it as a variation, and then do same with another variation ?
    my tests gave me the feeel that this is exactly NOT working ! but i wonder if i was wrong

links to specific spots in the manual would be welcome too ofcourse.
i´m not to much at home in the manual since it operates based on real live examples, and its like i had to read it like it was a book.

but maybe some few words are possib le on my points 1 and 2.
i just need to understand what “should” work.

my goal:
i have a given “patch” in GP ( a rackspace/ usually set to “back view” )
and i want to have different parameter settings that i´d like to save and laod like a whole “snapshot” of the patch in a given state

edit: btw. i need to contact a moderator, (or somebody of the GP related ones)
i have a message that i better post private.
i stumbled over something while i wrote this post.
can somebody of you hit me up per PM please ?

In short, you have a rackspace, and you take the parameters of each plugin in that rackspace that you want to vary and you assign them to widgets. You’re not changing the plugins themselves, adding more or less of them. A variation uses exactly the same plugin blocks as the rackspace it comes from.

Each variation of that rackspace can have different values for the widgets you’ve created for it. It’s the widget values that you change with every variation.

For example, one rackspace (or 'patch, as you called it) contains a piano plugin, a reverb plugin, and a delay plugin.


You want Variation A where there’s no reverb just delay, Variation B where there’s no delay just reverb, Variation C with a little of delay and a lot of reverb, and Variation D with a lot of delay and a little reverb.

In that case, you’d need a widget to bypass the Reverb plugin (a switch), a widget to bypass the Delay plugin (a switch), a widget to control the volume of the Delay(a dial), and a widget to control the volume of the Reverb (a dial).

Variation A You turn the Reverb bypass widget on. ( this bypasses the Reverb plugin)
703
Variation B You turn the Reverb bypass widget off, and turn the Delay bypass widget on. (this turns the Reverb back on, and bypasses the Delay plugin)
704
Variation C You turn both Reverb and Delay bypass widgets off, you adjust the Delay Volume widget down, and adjust the Reverb Volume widget up.
706
Variation D You adjust the Delay Volume widget up, and adjust the Reverb Volume widget down.
707

Does that make more sense?

5 Likes

To make it short (in addition to the great explanation & examples, from @edm11):
A variation only stores the states of the widgets that are on your rackspace panel, nothing else. Just the widgets. All other parameters that are not “reflected” by a widget won’t be captured within a variation.

If you want to store the complete state of the other parameters that are not represented by rackspace-widgets, you have to create another rackspace, because a rackspace holds every state of every plugin that is used in it, no matter if you have bound this parameter to an own widget or not.

3 Likes

@edm11, that was a very thourough answer ! Thank you very much !

@schamass, thanks for doubling !

OK, i see !
thats VERY useful to know for me, in addition to above.
So i see now very clear ! great, great, great :wink:

to create widgets for all parameters i´d want to be changed from “Variation” to “Variation” seems not very practicable for me, in most cases at least.
But switching rackpsaces seems very fine, since i do the “live play” thing in my Homestudio " without any “live on stage” pressure etc. .

I´ll definitly keep both possibilitys in my backhead and will continue accordingly with creating my “patches” ( Rackspaces)…and exploring possibilitys
to have these two options will make GP even way more useful and powerful for me !
Wow, its HUGE, Love it !

1 Like

It’s worth understanding philosophically the purpose of widgets and variations. They were never intended to allow many parameters to be changed simultaneously. The idea was to expose solely those parameters that one might want to change during a performance. During sound creation, you might tweak lots of parameters in the plugin editor itself but when you start playing, one typically wants to do things like control filter cutoff, maybe a bit of ADSR (maybe just the D), perhaps portamento and so you’d make those be widgets that you could either control in real time or instantly switch them (by switching variations).

So if you’re a guitarist, you might have 3 or 4 effects available and different variations might just turn different sets of those parameters on or off together.

I get the sense that since you’re coming from the modular world where people typically “evolve” the sound, you need to have much more access to all parameters.

For what it’s worth, it is possible to use OSC to access and change arbitrary plugin parameters on the fly over the network and it may be that you want to think about using a tool that can send arbitrary OSC messages into Gig Performer. However, doing this requires some knowledge of OSC and tools like Max, Bidule or M4L to create/organize a large collection of OSC messages.

1 Like

this is how i use the widgets.
Also, since there are some limitations in regards to HW control,
But even more so is the whole “overlookability”, Rackspace vs. loading the next Rackspace a real issue. ( to remember what the HW controls are mapped to )
Since i do quite different things from rackspace to rackspace
( so far do i only use one rackspace per “project” )
So, keeping the hardware controls reasonable has advantages anyway.
To use new rackspaces to create “variations” might be the solution i will have to focus towards.

To just map even more parameters to a “patch” ( rackspace) seems doable ,…
but just when i get to have some finalised patches.
But i have to become way way more familar to layout those front panels with the widgets first :wink:

this is good to know that this is doable !
but its finally beyond of what i´m capable of, since i´m a computer dumb :wink:

Thanks

It is never too late to learn new skills!

2 Likes

If you’re too lazy to create widgets for all parameters you want to control, you could adjust your parameters and create presets in the plugin and recall them with midi program changes or something like that

Please see https://gigperformer.com/rackspaces-vs-program-changes/

It’s generally better to just use multiple rackspaces.

1 Like

this has nothing to do with lazyness, at least not at a first place.
…and it finally seems not feasable what you´re saying. at least not for me.

its probably also a thing of how complex a patch of mine can be.
And mainly, how much importancy i give, to have a front rackspace that is nicely overlookable for jammings (mirroring my hardware control setup) , …and some further mappings when needed.
…even after weeks of not using it, and coming back freshly, …so that i first can have a easy access to learn again what the point of my “patch” (gig or rackspace) was.

also keeping my whole FX-presets count as overlookable as possible is a major concern of mine.

Finally, was creating front-rackspaces quite workloady for me, so far.
not shure how many “tricks to have” i´m missing here so far.