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

General discussion about Gig Performer
1

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 ?

2

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.

702
702736×638 37.1 KB

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?

7 Likes
3

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
4

@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
5

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
6

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

7

It is never too late to learn new skills!

3 Likes
8

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

9

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

It’s generally better to just use multiple rackspaces.

1 Like
10

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.

11

I also find it cumbersome how GP deals with plugin presets. See my reply to another thread Duplicated rackspace that differs only in the preset loaded into a plugin

12

How much of this is because you are trying to use GP the same way as you used a previous host. GP’s paradigm is quite different (and provides functionality you couldn’t previous have) and so trying to use it the way you used other hosts is perhaps like trying to push a square peg into a round hole.

3 Likes
13

just to made this clear:
i did not say its cumbersome ( since you sayed: “also” )

but i agree that i also see some “potential” to further enhance the functionality of GP3,
anyway when its about studio-use cases.

I had my own thoughts vs. creating a third type of form of how GP could deal with rackspaces,
a type of “Rack-presets”,

A real given point, where a “inbetween” between “Rackspace-Variations” and just “doubled-Rackspaces” with further changed parameters would come in more than just handy, is:

the widgets…and further development of the widgets over time! (within given Rackspaces)
if we could have a third form of dealing with Rackspaces, that:
_would just deal with one “Patch” ( you call it a Rackspace in GP)
( while “your” Rackspaces could in fact contain different (what i call) “patches” ( the back view), one rackspace vs. the other )

So, any further level of a “preset” you would create ( a new, third form of dealing with “Rackspaces”, /…in that sense, beeing a second form of “Variation” ) would share the same "front Rackspace with all its widgets and range settings,
so if you would change or readjust one widget /or its inner “range” settings, would it be applyed to any other “Rack-Preset” within that “Rackspace”.
To have THIS, would be über-awesome, and would help in my case to avoid alots of workflow problems and chaos that is created by me, within all the files that i create ( have to create).

While this type of “Rack-preset” would allow for changes of parameters that are NOT covered by widgets within the backview of a rack, and also would allow for changing presets within a plugin ( i see, there are some open questions here vs. preset changes on Plugins)

I mean: i have all the time to double my Rackspaces, ( and NOT creating “Variations” since it has its limitations), but i allways would further develope my widgets from there,
so i end up with lots of gig files, within those often with same rackspaces ( just the parameters of the plugins changed) , but then, …would some of these Racks evolve better than others when it comes to further development of the widgets and their settings.
This creates for me alots of work , but also confusion, and is somehow a blocking factor for developing my “rackspaces” further and further.
… i pesonally can´t boil down my workflow into something more coherent and efficient.
Whatever i do, i end up with chaos, …too many files, and no good overview at the end.

What is missed “for me” is indeed the inbetween between a “Variation” (sharing the same Front rackspace / and finally also the back rackspace,
and the "new/copy Rackspace " workflow, which allows for the parameter changes, but would no longer share the front racksapce with its widgets and (inner) settings.

there´s the Gap !

( its NOT complaining what i´m doing !
i´m every day where i can use GigPerformer super super thankful that it exists !
…i´m just very vocal on: where i see potential for further development ( beeing fully aware that you for shure have your own basket full with things that you´d like to add, or rework, or refine…:wink: )

14

I have missed the obvious: EG: “how do I select Rackspace 13 Variation D from my MIDI Controller?” It would seem that just sending a PC doesn’t address a specific variation other than the default variation.

15

@Phil Click on the variation itself, check the Assign Program Change Number box, and assign it a PC number.

755

1 Like
16

Is it better to:

  1. setup a Rackspace that let’s say uses “Blue3” as an organ
  2. setup 9 slider drawbar widgets (of course you could extend that with another 9 for the bottom manual and another 2 for the bass)
  3. Learn the sliders from my MIDI conrtroller
  4. Create a variation for each possible drawbar setting I use during a performance
  5. Send a Variation Change for every time I want to change my drawbar settings
- or - 

1) Setup a Rackspace for each Blue3 drawbar setting and setup the fader widgets like above.
2) Send a PC for every time I want to change my drawbar settings

I would suppose they both would work, but using the second technique might create a lot of Rackspaces. Help?

17

As a rule, make a…
Variation if you’re using the same plugins as main rackspace, with different parameters of those plugins.
Rackspace if you’re using plugins that aren’t in the other rackspace(s).

So, in your example, if you just want to change drawbar settings, use widgets for the drawbars and set up variations of that rackspace.

1 Like
18

Where can look to see if anyone has already done this with Blue3 and is willing to share their rackspace?

19

Try this one.

Organ 2-manual template Blue 3.gig (101.9 KB)

1 Like
20

Wow! Thanks Rich … can’t wait to try it! :slight_smile: