I’m trying out GP as a possible replacement for Mainstage and have some thoughts and questions regarding how to reuse resource heavy AU instrument instances.
In Mainstage you can reuse AU instances by using “aliases”. This is good practice to do for resource heavy plugins. In my case I have UVI workstation with Ravenscroft 275 and Kontakt player with the Scarbee classic EP-88S. I have mapped controls for many aspects of these instruments (e.g. vol, rev, wah and so on), and these settings are then saved with each alias instance. This works well in Mainstage with one exception which is when I want to introduce a new aspect to control. As an example, say I would like to have tremolo on some alias instances of the Scarbee but not on others. What happens is that I add and map controls for tremolo and tweak them for the song at hand. Then, when I switch to an already existing alias that does not have any saved tremolo control values, the tremolo will still be applied, which is not wanted. I see why it happens but it makes the concert a bit unpredictable over time. To mitigate it I have to find all alias instances in the concert and save tremolo control values to each of them.
In GP I have found that I can achieve a similar setup by having the resource heavy AU instruments loaded once and for all in the global rackspace. Widgets for controlling aspects of the plugins are added to the global rackspace as well. In each regular rackspace I then have a new set of controls targeting the global rackspace controls in order to have different settings per rackspace and variation. It works well but it has the same limitation as Mainstage regarding the procedure of adding new aspects to control later on. Having duplicate levels of widget controls is a bit tedious as well.
I wish something like this would be possible (maybe it already is):
When you add a widget in the global rackspace, you can optionally set a default value that will be applied if not overridden when the rackspace or variant is loaded. The initial value should be the current value of the parameter it is referring to. This would allow for a shared plugin to have new controllable parameters added incrementally over time, without risking to change the sound of existing rackspaces and variants.
To mitigate managing two levels of widgets (global knob to instrument param AND regular rackspace knob to global knob) I would like to have the ability to alter and save global widget parameters on a rackspace and variant level.
Maybe I try to use GP in a way that it is not supposed to be used. I get the feeling that the GP approach is to keep it simple and just have multiple instances of the same plugin if it gets too complex to share since GP will preload your next patch in a smart way.
Widgets within the global rackspace are not controlled by rackspaces/variations unless you create special parameters and widgets. This answers the second question…
To do this you assign a parameter name to a global widget, then drop a regular widget in a regular rackspace, connect it to the To or From global rackspace plugin and select that parameter.
All of this is in the manual…
MS aliases … do not try to optimize your gig file before you have to optimize it.
Best practice is NOT to cram everything into one rackspace - be it global or local.
Create one rackspace per sound and insert your plugin into these over and over again. If you do need to use “aliases” later because of RAM - just turn on GPs predictive loading feature and it will automatically create/use aliases for you.
Thanks for your reply!
I have not tried a 2nd instance of Gig Performer. I might be missing something but I think it would have the same issue when it comes to add new aspects to the Variations later on.
Resource heavy in this example would be RAM usage and load time.
Yep, I meant Variations with Variants. Sorry for the confusion.
Thanks for your reply!
I think the “special parameter and widgets” you mentioned is what I use already when selecting “From Global Rackspace” as the plugin. My point with bullet nr 2 was that it takes two levels of “knob” management to adjust parameters defined in the global rackspace, from the “normal” rackspace. If this could be avoided I would prefer it but it is not a deal breaker either.
Bullet nr 1 would be more crucial to me. I.e. the ability to propagate a default value for a global widget, that is applied at rackspace/variation load time if not overridden at that level.
I did try with predictive loading. I think it is a smart idea but I also think it is more suited for when having lots of different heavy plugins/libraries, not when using the same ones in almost every patch, just slightly altered. What happened was that I got loading Kontakt dialog when changing rackspace - see image.
I hear what you are saying regarding “if it ain’t broke…”. On the other hand, I think the Gig Performer seems really powerful and flexible, and that opens it up for many ways of usages. I think the use case I described is not that far-fetched but maybe I’m off on a tangent.
Sorry I do not get it.
You can set a value of a global widget in sync to a value of a local widget when Ignore Variation is not checked.
Is that not working for you?
Regarding Kontakt, do you know how to purge the sample pool in Kontakt?
First of all, thanks again for the prompt and accurate response! I see why this forum has a good reputation.
As I understand, not checking Ignore Variation makes it possible to override the value in the Variation. What I want ia to reset it to the global widget value at Variation load time if the local widget does not exist or if it exist but is not saved with a specific value. Does it make sense?
Will check sample purging as well. Thanks for the tip.
Are you suggesting that a new option is added to the widget properties for this behaviour?
The global widget value is constantly changing, so I assume you mean you want the global widget to reset to whatever its ‘Default’ value is set to (or some other dedicated field)?
Scipting might be an option. Is it possible to have a script defined globally that is triggered when a rackspace/variation is loaded? The script should iterate through all widgets in the global rackspace. For each of these, if there is no local widget defined for that parameter then apply default value defined globally.
Yes that could work, but you should think about a more streamlined solution.
Because the existance of a widget does not state that it is mapped to the global.
For correct work the script should check, if a global mapping is made
Next we’ll be getting asked to implement Javascript
There is no such concept of iterating all widgets. Widgets are given script names and declared as first class variables in GPScript, tightly locked to the underlying implementation for efficiency. If the widget does not have an associated GP Script name, it cannot be defined in a script.
More importantly, just as we have told the Forte users to stop trying to make Gig Performer behave like Forte, don’t try to make Gig Performer behave like MainStage - the paradigm is completely different and it seems to me you’re trying to do premature optimization before you have even determined there’s an issue.
I am doing something quite close to what you describe here in the new rackspace template I am building right now, but I don’t do it for me same reason…
At your level of GP discovery, you should take some time to try to use GP as GP rather than as MainStage. A lot of things are already optimized in GP so that you can use it without having to worry about it. Try to pretend you never used MainStage and go a little further with GP. If you really have optimization problems, we can always see how to do it.
