Problem with JUCE based Plugins


I had written a scriptlet for Gig Performer 4 that allowed controlling all parameters of my SY1000 Guitar Synth.

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 can confirm an Mac.
The same happens with Blue3
With the inbuilt MIDI In Plugin (mapped to chanel1 output) it does not happen.

Hmm seems to work OK on Windows PC

Both Rackspace and Plugin move both knobs if they are on the same group.
keys-juce-2021-09-03.gig (37.2 KB)

Except I’m using maybe a different plugin. Maybe mine is not JUCE based but I really don’t know how to tell.



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.


They should be not on the same group, only mapped to the same plugin parameter.

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.


I don’t think it is an “error”. When a plugin has a parameter modified there are two possibilities:

  • the plugin take the new parameter into account ,changes its internal values accordingly and that’s it
  • the plugin take the new parameter into account ,changes its internal values accordingly and sends back out the value it just received

I am not sure there is a standard for plugin regarding this behavior.

But in GP we can group widgets and map only one of them to the plugin parameter. :wink:

Use this Rackspace Script to link the widgets. Make sure you assign the proper GPScript names (handles):

   lengtha : Widget
   lengthb : Widget

// Called when a single widget value has changed

On WidgetValueChanged(newValue : double ) from lengtha

If  GetWidgetValue(lengthb) != newValue
	    SetWidgetValue(lengthb, GetWidgetValue(lengtha))
  On WidgetValueChanged(newValue : double ) from lengthb

    If  GetWidgetValue(lengtha) != newValue
	    SetWidgetValue(lengtha, GetWidgetValue(lengthb))



1 Like

Hello Steve,

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.

Which situation?


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?


Please, no!

And by the way your script could be much simpler as GP4 callbacks are not called if the value didn’t change, so this prevents infinite loops.


Yes it could probably be simpler but I didn’t want to take any chances so I put in the if statements.

I thought if I didn’t

  1. change lenthga
  2. Callback to change lengthb
  3. which calls lengthb callback
  4. which calls lengtha callback
    … infinite

So change only made to the other widget if the values are not equal.