PluginParameterChanged event not raised for many paramters

[nlaroche]

I've noticed that for many parameters on different plugins that there is no change event which is raised when the parameter is modified by the user. I've been reviewing the code trying to understand if this is intentional or a bug but I'm still not sure - I believe it has to do with slider type. This is important for my use of the YSFX library so that I can react to the user changes as the plugin host

Examples:

• Lava verb: https://github.com/JoepVanlier/JSFX
  -- The sliders in the "Ring" work notify host however the options in the middle do not
• Atlantis reverb: https://github.com/geraintluff/jsfx
  -- None of these raise changes

I'd be happy to make the changes on my side if you could advise and point me in the right direction.

Thanks!

[jpcima]

Hi @nlaroche

I noticed something curious before, in Reaper, which I think related:
when one sets a slider by code, and doesn't invoke either sliderchange / slider_automate on that slider, Reaper will still pick it up and perform the value change.

Indeed, Ysfx doesn't replicate that behavior, which is probably a problem.
I have to admit, if host picks up slider changes by itself, I don't know what's the purpose of sliderchange at all.

(On another note, Ysfx-plugin has sliderchange & slider_automate both automate value; there is not in VST a notion of non-automating "change" like Reaper has)

[nlaroche]

Hi,

Thanks for the response. I really don't know how Reaper is picking up the changes - in my code I am using pluginInstance->addListener(...) to listen for the changes and this is why I'm noticing the issue. My application is a multiplayer daw for remote collaboration, essentially, so I capture parameter changes and synchornize them with other users in the session (this is working already for some jsfx via the ysfx library).

In the YSFX code in handleParameterValue() simply changing setValue to use juce::sendNotification instead of dontSendNotification works for some parameters and allows me to capture the events, but handleParameterValue() is not called in the examples I've listed in the original post - I just can't figure out why for some sliders it is captured and works properly but for other sliders it is not.

I think its how parameters are bound. If you're not sure I can dig a bit more.

Cheers!

[jpcima]

You can try to experiment with this quick patch (not tested) b85d5da

This should make the plugin report value changes regardless whether the jsfx sets the change bit or not.
That might make it closer to the Reaper behavior.

[nlaroche]

Awesome, thank you for the quick replies and changes ! I will give it a shot and see if it helps.

[nlaroche]

Unfortunately this fix did not appear to change anything, but I did discover in one case (Atlantis-Reverb) that when I switch to slider mode, as a host I will always receive change notifications to the parameter. However, that same parameter in graphic mode does not trigger the notification change message.... but, if I switch back to slider view, I can see that the slider component has updated.

So there is a change notification getting lost somehow when updating certain parameters in graphic mode it appears. Still investigating why..

[nlaroche]

I figured out the issue. When changing a parameter in GFX mode YsfxSliderParameterComponent::isDragging = false, and this does not trigger the sliderValueChanged() method containing the setValueNotifyingHost method.

I've made the change for the slider parameter and similar changes for the other types, however I did not do a PR as I'm not sure if this breaks anything for the way you envision ysfx should work (also im still testing this a bit more thoroughly, might be buggy in some situations).

Here's the code for the slider. Hope this helps and thanks again for creating this amazing library!

    void handleNewParameterValue() override
    {
        if (!isDragging)
        {
            if (getParameter().getValue() != (float)slider.getValue())
            {
                getParameter().setValueNotifyingHost(getParameter().getValue());
                slider.setValue(getParameter().getValue(), juce::dontSendNotification);
                updateTextDisplay();
            }
        }
    }

    void sliderValueChanged()
    {
        auto newVal = (float)slider.getValue();

        if (getParameter().getValue() != newVal) {
            if (!isDragging)
                getParameter().beginChangeGesture();

            getParameter().setValueNotifyingHost((float)slider.getValue());
            updateTextDisplay();

            if (!isDragging)
                getParameter().endChangeGesture();
        }
    }

[jpcima]

I doubt it, this code is nearly a direct copy from Juce's generic parameter editor, except it takes its ranges from the Jsfx min-max slider specifications.

handleNewParameterValue is for letting the UI slider change it's value to match the param, it doesn't notify in the other direction.

I'm going to try reproducing the situation, but let me know if I should do something specific.

[jpcima]

It works in this commit 99d3c34 which is a modification of b85d5da

The deeper problem here though, it's that setValueNotifyingHost is refusing to notifying when it comes from the audio thread.
Deferred on the UI thread, it works. Likely something to do with the Vst3 implementation in Juce.

This solution is not valid as it is a proper fix however. (not RT, and unsafe)
Please give it a check if you don't mind.

[nlaroche]

Its possible the message thread is the issue, vst3 does have weird limitations about only calling things on the message thread in many scenarios. I'll have to give it a shot and see.

[jpcima]

Hopefully that one should work 1821b19