Hi all, is there anyway to change a VST3 preset in different Rack Variations.
I know that VST3 SDK and preset managing are still a “mistery” for most DAWS around but is there anyway to save the preset of a VST3 for different Rack Variations so i can just change the VST3 preset changing the Rack Variation via a MIDI program change?
thanks
But better you use different rackspaces because switching presets while playing will never be as smooth as patch persist is.
Thanks @pianopaul!
I’m mostly an improvising musician so during my live sets i may need to choose among a great amount of my personal presets. Probably having 32 or more copies of a rackspace (and if i have two or more plugins the number would increase hugely) is not so confortable.
I’m testing GP right now because i want to check if it fit my needs.
I admit that my needs are not so common probably since i don’t use fixed playlists in my live gigs.
I work with Ableton Live but its CPU requirements are more and more demanding even on my i9 9900K laptop workstation. So for more keyboard/fx oriented gigs i’d like to check some alternatives.
If it works good i could even thing of using it with jack audio toolkit to use my custom MaxMSP patches…
Why not?
@dhj because if i have 2 plugins with 32 presets each the possible combinations are 32*32…
probably creating 1024 rackspaces or variation is a total waste of programming time.
Probably controlling directly the VST presets is way far more confortable.
OK, what is your vst?
No elegant, but you can MIDI Map next/previous Preset to a cc message.
Use a widget an send a cc message to the MIDI In plugin connected to the OB-X and Midi learn
Another option is to save a preset via GP
And then you can react in scripting on a variation change and load that preset by name.
BUT AGAIN: You loose the possibility of patch persist.
In general: It depends on the plugin, if specific presets can be recalled by specific PC or CC Messages.
What I saw with OB-X, that is not directly possible.
For example save 3 presets via the GP menu as A,B,C
Yeah, you could use the LoadGPPreset function.
I just tested it with the Arutira DX7 and it works fine.
However, note that that function is still marked as experimental as there hasn’t been enough experience with using this approach to ensure that it’s totally safe
OK, do you have access to the GP user manual?
https://gigperformer.com/docs/GP4UserManual/rackspace-properties.html
Patch persist means that you can play a Note, hold it and switch to a different racksoace with a total different sound or even plugin.
And while you are holding the key the old sound remains and the when you play a new note the new sound is triggered.
Very useful when switching between sounds.
That is not possible when changing a preset.
1 Like
Could i make a script that react at a CC or Program Change and recall a GP preset by name?
Try this
OBX.gig (47.9 KB)
Load this gig file and save 3 presets via GP menu with name A, B and C
When you switch between the variations then the desired preset is loaded
and this is the script used:
//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
OBX : PluginBlock
//$</AutoDeclare>
// Called when you switch variations
On Variation(oldVariation : integer, newVariation : integer)
if newVariation == 0 then
LoadGPPreset( OBX, "A" )
elsif newVariation == 1 then
LoadGPPreset( OBX, "B" )
elsif newVariation == 2 then
LoadGPPreset( OBX, "C" )
end
End
You could also include a widget and depending on the value of the widget load a preset.
There is a function on WidgetValuChanged() which can be used.
And you map a hardware controller to your widget
So when you move your controller, the widget is moved and scripting loads a preset.
Or you assign a PC number to your variation and the above shown script reacts on that variation change.
Or you use the function on ControlChangeEvent and parse the incoming CC message and load the desired preset
You see many possibilities
But in my opinion: build different rackspaces with sounds of the same or different plugins and you will be more than excited about patch persist 
Do not try to use GP like you would use a real hardware or other DAW, look at the possibilities and design of GP and you will see a universe of flexible possibilities.
2 Likes
You can actually get even more cute than this.
For example, if you save your presets with names “A”, “B”, “C” (obviously any names you want, this is just for example) and you give your variations the same names, then you can simplify that callback as follows:
On Variation(oldVariation : integer, newVariation : integer)
var
name : String = GetVariationName(newVariation) // Get the variation name
LoadGPPreset(DX7, name) // Assumes there is a preset for the DX7 with the same name
End
What’s really nice about this approach is
- You don’t have to edit the script every time you add another preset
- The variation tells you the name of the preset
8 Likes
Thanks for all the hint guys!
@pianopaul i see the good advantage of Patch persist with a fixed set-list in a gig where you have to change presets very quickly. And i’ll gonna use it for sure for this kind of gig.
In my kind of average gig i prefer to get the flexibility of mapping with script a given CC value to a GPPreset.
Anyway scripting open a whole horizon! that’s great.
thanks again
1 Like
You are welcome.
Feel free to ask and be sure: No question is a silly question, we all will help you.
2 Likes
One of the original goals of Gig Performer was to be able to control it via OSC and in particular to be able to send “MIDI messages” over OSC so as to be able to use MaxMSP (which I used for years and have hundreds of abstractions) to do MIDI processing. In that mode, Gig Performer behaves as a powerful VST host “server” but you drive it from Max. I have used tools like Loopback and Blackhole to send audio between Max and GP as well - on Windows you can use virtual cable the same way.
Jack has never worked well for me (nothing to do with Gig Performer, I just found it to be a very clumsy approach vs just using virtual cables)
1 Like
@pianopaul and staying on the topic of silly question after a quick look at the language manual seems that the MIDI events are ignoring MIDI channel…
For example on
On ControlChangeEvent (c : ControlChangeMessage) Matching 1
it would respond to a CC1 on any MIDI channel right?
In my TouchOSC layout i have literally hundreds of parameters so i used more MIDI channels and used the MIDI learn feature on Ableton Live to map my layout widgets to all my relevant parameters in the LiveSet…