The scriptlet impressively showed the enormous possibilities of GP Script, but it was not really usable in practice, because it simply had too many lines of code. At every start Gig Performer was busy for minutes compiling these huge scriptlet and it also caused crashes due to lack of resources.
I have therefore spent the last few months getting to grips with plugin development using C++ JUCE and would now like to make the original GP Scriptlet idea available as a VST3 plugin specifically for Gig Performer users.
The plugin is almost finished. However, I ran into a problem that affects not only my plugin but probably all JUCE based plugins. ???
You can reproduce this error for example with the JUCE based plugin from “Lostin 70s”.
Link multiple widgets with the same plugin parameter. When you change the parameter on the plugin GUI, all GP widgets are updated.
But when you change one widget on the rackspace , the plugin parameter is changed accordingly, but not the other widgets on the rackspace, which are linked to the same plugin parameter.
I tried DevilSpring and get the same results however in my first example I grouped the 2 widgets and had each knob pointing to a different plugin parameter.
I my latest test, the widgets are not grouped and I believe that the widgets need to be grouped in order to work together. Since they are pointing to the same plugin knob they cannot be grouped in Gig Performer, however when moving the knob in the plugin, they indeed do control both rackspace knobs.
So the user issue seems to be that you cannot group 2 knobs together that point to the same plugin parameter in Gig Performer however I’m not sure why you would want to do this anyway. If they are not grouped, I guess the issue is that the feedback from the plugin only affects the knob that was moved in GP which is probably by design.
Yes I see the issue now but iI’ not sure it is a bug. The only reason I see that the user would want to do this is If two separate blocks each need to control the same plugin parameter but each using a different GP widget. I think you would need to script something to keep them in sync. I would see no reason why a plugin should provide feedback to a GP widget that did not initiate the movement unless they were in the same group.
Use this Rackspace Script to link the widgets. Make sure you assign the proper GPScript names (handles):
//$<AutoDeclare>
// DO NOT EDIT THIS SECTION MANUALLY
Var
lengtha : Widget
lengthb : Widget
//$</AutoDeclare>
// Called when a single widget value has changed
On WidgetValueChanged(newValue : double ) from lengtha
If GetWidgetValue(lengthb) != newValue
Then
SetWidgetValue(lengthb, GetWidgetValue(lengtha))
End
End
On WidgetValueChanged(newValue : double ) from lengthb
If GetWidgetValue(lengtha) != newValue
Then
SetWidgetValue(lengtha, GetWidgetValue(lengthb))
End
End
Thanks for your tests and the workaround script. But as you already tested by yourself, the update of multiple linked widgets works fine for other plugins.
I first assumed a programming error in my plugin. But I noticed that other plugins, which were written with the same C++ framework, also show this behavior.
In the meantime I received an explanation from another side, which is congruent with the answer from David-san.
If the plugin itself changes a parameter, it must inform the plugin host about this change, so that the host can update its linked controls.
However, the JUCE framework does not seem to have any built-in methods to inform the host about a parameter change, when the host itself has triggered this parameter change.
Therefore, the other widgets do not update because they do not get a hint from the plugin to do so.
Hmm, this is probably by design — you’d get a nasty infinite loop in this situation — presumably the host “knows” it set the plugin parameter so it doesn’t need a confirmation back from the plugin.
With the script I did, everything worked and since I used an if statement there is no infinite loop. I tested on Windows and all works so maybe the JUCE plugin problem is only on Mac?
