Attached Controls shouldn't send notification on setValue()

I totally agree G-Mon which is why I would agree that your original suggestion is probably the right one, i.e. that in juce_AudioProcessorValueTreeState the dontSendNotification flag should be used.

I was merely responding to @daniel, in that if someone is expecting to listen to a slider to get parameter changes then I think it’s defensible to suggest that is the wrong way to handle it, however I can see why someone would attempt exactly that. Instead whatever is listening to the slider should also listen to the parameter changes IMO.

I am totally with both of you, that the better design will always listen to the parameter directly (that’s why I added the last paragraph of my first response).
I was only pointing out, that it breaks peoples code, that relied to the current behaviour.

If there is a situation, where the current behaviour is needed, is probably a futile discussion. I’m sure you can make up situations to fit for each side.

I’m in the luxury position not to take decisions for juce, so I leave it to them…

1 Like

I’ll look into this in more detail later today (need to wait until my FL studio download finishes :slight_smile:). Using AudioProcessorValueTreeState and SlideAttachments etc. is really the idiomatic way to do parameters nowadays and JUCE should really work when using these.

I’m still having FL Studio automation issues, so that might be something else. But it did fix my Sonar issues.

OK I just tried this in Sonar and I can’t seem to find anything wrong. I’ve modified JUCE’s audio demo plugin to use ValueTrees. Check out the following code:

https://drive.google.com/open?id=0B3yZpQ3OG9ShQ0tWd3l1NExLdEE

Ok, I reproduced it in the demo plugin, see here: https://www.youtube.com/watch?v=IuhYM3zdMBk

I added a Component that redraws itself all the time to add a bit of CPU usage. I set the range of the param to be: 0.1f, 100.0f, 0.001f

I think the range is they key, there needs to be a bit of rounding error so that p->getValue() != newValue even when the value hasn’t changed. There are different by about 1e-8

        const float newValue = state.getParameterRange (paramID)
                                  .convertTo0to1 (newUnnormalisedValue);

        if (p->getValue() != newValue)
            p->setValueNotifyingHost (newValue);

Updated code link: https://www.dropbox.com/s/d3y47mezdbm8l1w/audio%20plugin%20demo.zip?dl=0

Here it is in FL Studio 12.3: https://www.youtube.com/watch?v=y3cuCYK5RJk&feature=youtu.be

The slider doesn’t even move unless I click on the automation clip. These are both on Windows 10 BTW.

Did you manage to reproduce the issue with my updated demo plugin code?

Still on this… I can reproduce this in FL Studio but not in Sonar. As you’ve mentioned, FL Studio does a lot of strange stuff with parameters.

I’m using Sonar Platinum 22.5.0 BUILD 45 [2016.05] - x64 on Windows 10
I’m using the VST2 64 bit build of the demo plugin I posted, build against the latest develop code

I’m automating gain and it looks like this:

I think I’ve found the issue with FL Studio, not sure how to fix. FL Studio stops automating the parameter whenever setValueNotifyingHost() is called.

I think there is a race condition with the AudioProcessorValueTreeState. setValue() is called by the engine thread and updates the value variable, which triggers a timer that copies the new value into the ValueTree. The timer, in the message thread, calls updateFromValueTree() compares the newValue against value (which by now may have been updated by the engine) and if they are different, calls setValueNotifyingHost().

Not sure the correct way to fix this, but the plugin should never call setValueNotifyingHost() unless the plugin is causing a parameter value to change, either through user UI interaction or loading a new preset, etc.

I know you guys have been busy, but will you have a chance to look at this soon? I’m hoping to get a plugin released by the end of the month. Here is a video of automation stopping in Studio One 3.3.1. It takes a while to happen, it took about 3 minutes of playback before the issue showed up. https://www.youtube.com/watch?v=vzP2Zbag3ec&feature=youtu.be

Here is the updated sample plugin code. You wouldn’t have been able to reproduce the issue in the previous code I uploaded unless you were loading a preset first. The constructor of JuceDemoPluginAudioProcessor wasn’t giving the state a valid ValueTree. I also made the CPUWaster class auto adjust, maybe you have a faster machine than I do and it wasn’t wasting enough CPU.

This is just a heads-up that I’ve been looking at this for a while. It’s quite a tricky problem, but a fix is coming.

1 Like

I have an ugly hack that seems to have fixed it.

void copyValueToValueTree()
{
    if (state.isValid())
    {
        updateLocked = true;
        state.setProperty (owner.valuePropertyID, value, owner.undoManager);
        updateLocked = false;
    }
}

and

// This method can't be used until the parameter has been attached to a processor!
jassert (processor != nullptr && parameterIndex >= 0);

if (! updateLocked)
    processor->setParameterNotifyingHost (parameterIndex, newValue);

}

I find it hard to follow the logic of how the parameter system works with all the timers, callbacks, listeners, etc, etc. But as far as I understand, when a parameter gets updated, sometime later that value gets copied into the value tree. This should never get sent back to the host, so I have it blocked. Any other time the value tree is updated, the host does get notified.

That probably fixes it for the majority of cases. The trouble is that a simple solution like this is not thread safe - the copyValueToValueTree method is always called on the message thread, but you could update a parameter from any thread. If you’re unlucky then an important parameter update on a different thread would be missed.

I can’t think of why I would ever update a parameter from a thread. My audio thread only ever reads parameter values. Parameter values are only ever changed from UI interactions.

I guess if I implemented midi learn or something like that, they would cause parameter changes from the audio thread.

It’s not necessarily you, it might be the host, so see this thread:

…mind that the discussion continues, the solution of the first post using locking is not recommended…

I’ve just pushed a fix for this to develop.

Thanks, those changes look pretty invasive. I’ll test this soon.

Have there been any updates on this matter? I’m running into the same issue using Reaper.

EDIT: I updated to the latest version of juce and no long have this issue