On recalling a rackspace with vb3 it does bring up last saved preset , only brings up default welcome preset, any work around ?
Are you sure, or is only the preset name not changed and for example the drawbars are correctly restored?
It’s the same in any DAW as well. I’ve never got my head around the way VB3 Works with presets.
As Paul says it seems the plug in parameters do change but the name always seems to revert to default.
Just checked, the state is restored correctly.
the only way i can get the desired patch name to come up is
apply a slider widget
select VB3 PLUGIN
select parameter = program
select value in properties
set current widget value to say 51 (which= prgm 65 in vb3)
initial value on load = “this value” ticked
copy current value
also “on rackspace activation” ticked
set current widget value to zero = program 1 in VB3 etc
there may be a better way but this works for me
You should contact the support of vb3
1 Like
OK — here’s how this works.
Plugins can report back to a host their current “state”. The contents of that state obviously depend on the particular plugin but will typically be things like the current filter cutoff frequency, the values of the ADSR envelope if there is one (or two or three), oscillator frequencies, selected waveforms, etc.
Basically, the plugin will provide everything that is needed to restore that plugin back the way you left it. If the plugin developer forgot to include the filter cutoff (say) in the reported state, then everytime you restore that plugin, the filter cutoff would be at some random or default value. That would be a bug which would be reported to the developer.
However, there are aspects of a plugin that can not or should not be considered part of the state. Typically, a plugin’s built-in preset management system would be an example of this. Consider: suppose a plugin has a preset called “Strings”. You select that preset and all the parameters are adjusted so that you have a “String” sound.
Next, you tweak the filter cutoff frequency slightly, perhaps to make the strings slightly darker or brighter and then you save your gig (which means saving the state of the plugin, including that tweaked filter cutoff).
Then you reload your gig file. You expect the plugin to be restored the way you left it — i.e, with that filter cutoff tweak. So what would it mean then to display the “Strings” preset at this point? What is currently loaded is not that Strings preset.
So in fact it would mean nothing (worse, it would be misleading) to display that “Strings” preset at this point. That is why presets themselves are not stored as part of the state.
They are just a way to get to a particular starting point. Now it may be that after you have tweaked your Strings sound, you could save that as a new preset. That gives you a new starting point when you use the same plugin somewhere else, you can just recall the sound. But that’s all you get.
Note by the way, that even if a plugin doesn’t have its own preset system, Gig Performer is able to save plugin state in standalone files, which is essentially a GP plugin preset system.
1 Like
I had the exact same problem with VB3. It doesn’t honor individual program changes like you would expect.
What I had to do (and it works well) is to adjust the draw bars and settings manually. That info is saved individually with each rack space.
But you can load a preset and when you save the gig the settings are stored in the gig file.
Thanks for reply guys
Just got a confirmation from the devleoper of VB3 II
The issue that the preset name is not part of the plugin state will be fixed in the next update.
It’s not clear to me that’s a good change. What happens if you select preset A, tweak the parameters, and then save the state. When you reopen, it will say preset A but it really is not preset A any more.
Your are right, but most other plugins do that.
I always save my changes as a Preset.
when I want to record something in a DAW with the same sound as I use in Gig PerformerI just recall the preset.
Yes, but explicitly saving your tweaked sound is a different use case. If you don’t save it as a new preset and you later reload, you will be in the situation where the preset “claims” you are using a certain sound but in fact your sound is different and you’ll be left wondering what’s wrong (and possibly blaming Gig Performer)
Worse - consider what happens if a plugin does include the preset as part of the state, then what happens when you reload a tweaked plugin. GP will load it and then the reloading of the “Preset” will reset what was there which means that the tweaked sound that you saved in Gig Performer (without an explicit saving of the preset) will be gone and again, GP will be blamed for not restoring the sound.
Just the Preset Name should be shown, the preset itself should not be loaded.
Right – but if you do that but your sound was tweaked, you are now displaying a preset that is not actually what is loaded.
To make this clearer, suppose you recall the preset “Strings”.
Now you tweak all the parameters such that you have changed the string sound to a flute! You then save your gigfile. When you later reload, you will be hearing a flute but the preset will “claim” they’re strings.
That seems wrong to me.
Your are absolutely right from the aspect of how the sound is.
Blue3 works this way, the preset name is part of the plugin state.
It is the same with Omnisphere and Keyscape and many others.