Saving and recalling VSTi parameters in Variations without the need of Widgets

#1

Hi there,

widgets can be assigned to VTSi parameters and HW MIDI controls and thats great for parameters a user needs to control during the show. If user wants to store VSTi parameters (set via VTSi’s didicated UI) in a Variation in order to recall them later by activating this variation, then he would need to add and map Widgets for all of them even if he never wants to control any of them individually during the show.

It seems obvious, that it should be possible and may be (hopefully) not that much effort to store and recall (all or a selected subset of) VSTi paramters automatically without the need of adding and mapping extra Widgets for each of those parameters. Of course this feature might be activated by a checkbox in Variation properties.

This enables users to setup and apply different (and may be extensive) configurations of a VSTi each of them for a different part in a song very easily. Even if VSTi requires manual enabling of host automation it still would be much more easy to do it this way.

And even if todays implementation of “Variations” do not allow for this (due to internal SW architecture or whatever reason) may be some new items added to Rackspaces (like “Configurations”) can be implemented by the developer team.

#2

We’ve thought about this one and it is on our list albeit low priority - the concern has always been
a) How do you know which parameters to change - in fact you’d have to store/recall every single parameter and that could have a significant impact on the time to switch, depending on the plugin — better to use a different rackspace

b) Some parameter changes may cause significant delays (for example, if new samples have to be loaded) and we’re skeptical of that in a live performance

Having said that, if the plugin supports presets, then you can use the GPScriptFunction

 SelectPreset(pluginBlockName, presetIndex)

inside an On Variation callback to switch to a different preset

#3

I highliy appreciate, that you and your team are examining feature ideas very carefully before implementing them! I’m in this business too for more than 30 years and I know what could happen if things are not thought out right down to the smalles details.

a) Im still a bit new to VST but from my understanding, a VST host is able to read the list of parameter names from VSTi (if host automation is enabled) and then user may simply select (click) which parameters to track. Alternatively user may just move all controls in the VSTi’s UI (e.g. the Hammond Drawbars) to select them (like during learn). From all my VB3 controls e.g. I never experienced any noticeable deleay or any other realtime issues when I move controls (change paramerters) while playing this VSTi. Of course others may cause dropouts like keyscape during loading new samples when switching to another preset.

I guess sooner of later a user is famillar with his VSTi’s and parameter changes that are not “realtime capable” and finally user is responsible for the selection of parameters to include in variation switching. Due to performance reasons, of course on variation switching only those parameters, whose new value is different from current one sould be udpated.

b) I was also thinking about this solution but it requires an additional data base (the currently loaded VSTi Presets) to be “syncronized” to the gig file, i.e. for each new gig file user has to load appropiate presets in all VSTi’s affected. Can this be automated by GP too?

Using multiple Rackspaces instead of Variations would thwart the concept of using one rackspace per song and variations for parts within the song which require changes in VTIs parameters (e.g. making a sound much more assertive during a solo part). For me this concept seems to be much more intuitive and suitable compared to multiple rackspaces.

But last not least, I love GP and it’s definitely my choice for live performances!

#4

And some plugins will crash, leading users to believe erroneously that Gig Performer is unstable!

Why do you think that? Switching rackspaces is exactly what you would do in such cases.

#5

My statement was from user point of view. Song parts have a strong relation to each other, they are parts of the same song and they are typically played with a defined/constant set of intruments the Artist is playing in different style/expression and different parameters. Variations have a similar relation (like song parts) because they are created within (owned by) the same rackspace. Rackspaces do not have that releation between themselfs. So using a single rackspace for a song and variations for parts of this song was the intuitive model for me.

If I switch to the multiple-rackspaces model, then I do have to organize and manage this relation by myself, in my head by remembering which rackpace is which part of which song. May be a relation-naming-pattern could help a little bit, but this mode used to be supported and managed by the VST Host application, not by users brain.

Is this managed by the new setlist/song/part feature added in version 3? Unfortunately the users guide is a bit hard to read since the internal links do not work and my first try & error approaches in GP3 also couldn’t give me the answer.

#6

You could use multiple instances of the same plugin and then in the variations you could bypass what you do not need.
What plugins do you use which should change the preset by changing the variation?

1 Like
#7

Yes- it’s the whole point of songs and song parts. Each song part represents a particular rackspace/variation pair and the same rackspace/variation pair can be used in multiple song parts of multiple songs

There’s a version up there now with working links. Unfortunately some of the words are running together (missing spaces) due to some incompatibilities between Mac/Windows MS Word. We’re overhauling the entire document into a new system that will make it more convenient but can’t say when it will be done

#8

Yes, that’s a very effective approach

#9

Thanks so much dhj and pianopaul!! You are examining my questions deeply and that is excellent support!!

@pianopaul: I often use Keyscape, Omnisphere and VB3 II. The VB3 is a typical example for switching parameters from one song part to the next, e.g. a soft drawbar settings in verse and a harder more assertive one during chorus or especially in an organ solo part, may be in combination with other parameters like tube feedback, drive, and chorus settings in Amp / Rotary Leslie. These parameters all can be changed in realtime without any drawbacks, dropouts, delays or even chrashes. Furthermore VB3 II is never loading any new samples on preset switching, it just changes it’s parameters seamlessly. But yes, may be this is a special case due to the nature of this instrument.

I will go deeper into this new setlist/song/part concept to figure out if it is doing what I am missing.

Thanks again to both of you! Very good support!

#10

In omnisphere you could use the live mode, this cam be controlled by widgets.

#11

Thanks Paul for this tip!

#12

Here’s a blog article about using Omnisphere in live mode through Gig Performer

https://gigperformer.com/controlling-omnisphere-in-live-mode/

#13

Very helpfunl, thank you you!