I have Arturia V collection, which comes with a lot of great presets. I currently have this script which will load a preset from the Arturia OB-Xa plugin based on the variation name. I know this method doesn’t give me the patch persist feature, but I’m ok with that since I’ve tested it, it works fine, and I’ll never be changing presets in the middle of a song.
This script works great for switching presets on the fly, but my widgets don’t change based on the new preset’s parameters. I’ve mapped them correctly, and changing the plugin parameters with the widgets works once I’ve changed presets.
What I want is for the widgets to update based on the plugin parameter values so after I’ve loaded the preset, I can tweak it. It seems like Gigperformer works the other way around - updating the plugin parameters based on the widget values instead. So when I load a preset, the widget values are loaded to the values that they were previously. They are not updated based on the latest values from the plugin.
Overall - here is what I’m trying to do:
Load Arturia preset using script when variation changes (I already have this working - see script below)
Read Arturia parameters and update all widget values for that loaded preset/variation (knobs, buttons, and faders).
Is there a way to achieve #2 either through scripting or some other method?
Here is my script:
Var
OBXa: PluginBlock
On Variation(oldVariation : integer, newVariation : integer)
var
name : String = GetVariationName(newVariation) // Get the variation name
LoadGPPreset(OBXa, name) // Assumes there is a preset for the OB-Xa with the same name
End
Hi and welcome to the Gig Performer family.
Can you upload a small example gig file?
Is this happening only with the Arturia plugins?
Is this happening with all Arturia plugins?
Which plugin format do you use (VST/VST3/AU)? Have you tried with another plugin format? Are you on Mac or PC?
I just tried it here on my PC with the latest OP-Xa version in VST(2) format and i can reproduce the issue you described, btw it’s the same with VST3.
It almost looks like the widgets refresh before the new preset has been loaded, or something like that…
Let’s wait what @dhj says…
Thanks for the quick response. I’m glad you were able to reproduce this. Unfortunately, I can’t upload my gig file since I’m a new user. I’m running on Mac OS 12.6 (Monterey) and using the AU plugin. I’ve only tested this with Arturia Piano V2 and OP-Xa V plugins.
Whenever I use my script and then change a widget value, the widget value ends up out of sync with the plugin value. I can provide more detailed steps to reproduce this once I am able to upload my gig file.
Thanks @dhj! Here’s my gig file. I’m using GP version 4.1.5.
Here are some steps to reproduce:
Choose American Studio Grand variation under the Piano rack space
Update the brightness fader to the max value (value = 1). The brightness will increase.
Switch to the Upright Studio Variation and then back to the American Grand Variation. This will load a new upright piano preset and then re-load the American Grand preset in Piano V2 plugin.
Result: The Brightness fader still shows with a value of 1, but if you open the Piano V2 plugin, the brightness knob on the plugin shows a value of .359, so the widget and value of the plugin are now out of sync. I’m ok with a workaround if I can sync the controls via scripting, but I couldn’t find any documentation on how to accomplish that. Example Gig File.gig (745.7 KB)
Just to diagnose: When you create a widget, that loads the preset when you press it, does it work as expected?
In that case, you could try and use a one-shot trigger. Trigger that trigger from the on variation event and do the preset loading in the timer event (or whatever is the right name) of the trigger.
Some experimental features are exactly that: experimental, and they might have rough edges.
The next release (can’t provide a date though ) already has a GPScript function that will explicitly update all connected widgets – and is designed specifically to deal with plugins that do not announce their plugins after their state has changed — I’m surprised though that there’s a problem with Arturia plugins in this regard, they’re generally very good about making sure everything works properly
Thanks for everyone’s help. I was able to set the widget values based on the Arturia plugin parameter value, but it’s not an elegant solution:
SetWidgetValue(Fader1, GetParameter(PianoV2, 10))
Ideally, I’d like to:
Get all changed values from the plugin.
Update all widgets I have mapped to the plugin.
I can get number 1 by using the On ParameterValueChanged callback, but I don’t see any way to accomplish #2 without explicitly calling out each parameter and widget in my script like the above example, which would be tedious. I don’t see any way to lookup a parameter other than by providing the index value. If I could look it up via the text value, then I could give the widget a GPScript handle to match the parameter text value and avoid a lot of additional code, but I don’t think that’s possible. Am I missing something? Is there any way to get the mapping between the widget and plugin parameters?
Not in the currently released version.
As I mentioned above, the next version has a function to update all widgets which is really what you need and it’s intended explicitly to handle this situation where a plugin does not report its parameters after a state change. There is also GetWidgetPluginMappedParameterNumber but that wouldn’t actually be necessary given the update function.
You should however report this issue to Arturia — when the state is changed, a plugin should announce its parameters, in which case GP would be able to respond automatically and you would not need to use GPScript.
I’m not sure however why you don’t just put each sound you need in a different rackspace. I understand you want to be able to tweak stuff but you’re presumably not going to be doing that in the middle of a live performance.
The plugin does announce it’s parameters on a preset change. On a manual change of a preset, the connected widgets follow the changed states with no problems, but as soon as the preset change is initiated by the “on variation…” callback, the widgets won’t react on that.
That’s why I suspected some kind of race condition… i will try tomorrow if other plugins (non Arturia) react the same way, or if it’s actually only Arturia specific.
Oh I see. So what’s happening here is that the preset loading has to be done on the main thread (because sone plugins can’t handle being updated on other threads and wanted to avoid crashing risks). So widget updates and preset loading are asynchronous. It may be that by sleeping at the beginning of the On Variation (using a for loop on 4.5.8) might help.
Ok, so I tried putting a for loop before the preset change and that seems to work! Using sleep gave me a syntax error, so I just put a print statement there for now, but it loads the preset value for my widgets! It takes about a half a second to load, but that works for the time being. One question - how can I replace the print statement with a sleep() or wait statement? I didn’t see either in the docs, and I worry about generating too many logs.
On Variation(oldVariation : integer, newVariation : integer)
var name : String = GetVariationName(newVariation) // Get the variation name
Var i: Int
For i=0; i<=250; i = i+1 Do
Print("Looping through iteration " + i)
End
LoadGPPreset(PianoV2, name) // Assumes there is a preset for the PianoV2 with the same name
End
There is no sleep function in 4.5.8 (there is one in the next version, we noticed that people were using FOR loops for delays!) but you don’t need a Print statement, just a FOR loop with a large enough index (or use a nested one)
The Print won’t actually take any significant time because the actual printing has to happen on the main gui thread anyway
You’re not generating logs…it’s only in the log window
I’m still a little confused. If you always want the widget values to reflect the plugin parameters, do you not have “ignore variations” set for those widgets? If you have that option enabled, then you shouldn’t need to pause the script at all as GP should not be trying to reset the widgets to their last saved values when the variation changed
