VST3 Automation


#1

Hi all,

I’ve noticed that VST3 plug-ins (including the JuceDemoPlugin on the develop branch…) have an issue with automation. If you draw a simple straight ramp in a parameter’s automation lane, the parameter values wobble intermittently, which is easily noticeable with a GUI open and a big enough rotary.

I’ve reproduced this with 3.6.5 and 3.6.7 of the VST3 SDK.

I have managed to catch the call which is causing it, and it is coming from EditController::setParamNormalized in the VST3 SDK, which is occasionally being called by the host with a value slightly lower than is being set in JuceVST3Component::processParameterChanges in the wrapper.

This affects both Windows and Mac, Cubase v9 and 8.5.

I’m not entirely sure why this would be happening, perhaps someone here will have more of an idea!


#2

Which JUCE version are you using?
Maybe it is related to this change (i.e. it might fix your issue):

https://github.com/WeAreROLI/JUCE/commit/4dcce5083c9128989577617facf6bd7ed3bc67a3

Another thing I read about, that VST3 should send a second parameter value at the end of a block to allow to predict changes within a block, but IIRC it is not picked up yet. Maybe some confusion crept in there in the implementation…?


#3

Hi Daniel,

Sorry for the long reply time!
As I said in the original post, this was happening on the tip of develop (at the time) on the Demo Plugin project, so I was using whatever default settings are in that project.

If it is indeed that commit that has broken something, then can someone update the demo project to show how this problem can be fixed?


#4

I had a quick look into the demo (current state). It uses the old AudioParameterFloat classes. They come default as not discrete, so it shouldn’t change the values.
Maybe you can verify the latest tip, but from there I think it is something for the juce-team to look into.
Good luck.


#5

Hi Daniel,

I’ve just verified that this is indeed still an issue on the tip of develop, in exactly the same way as I outlined above.
I also checked VST2 which I was there, and that does not show the issue, so it’s isolated to VST3 from what I can tell.

Agreed that it’s something for the JUCE team to look it to!

Luke.


#6

After a little more investigation, I’ve discovered that this started happening from tagged version 4.2.4.
The tag at 4.2.3 does not have this problem.


#7

Finally found the problem:
https://github.com/WeAreROLI/JUCE/commit/4cf3c02998db106517f99bc5fec26e070b681671

Taking this line away stops the parameters wobbling, but there is no information in the commit message about what exactly this line is fixing.

Can anyone (perhaps the commit author) offer some insight before I remove it for my builds?


#8

you may be particularly unlucky here because @fabian has just stated that he’s taking a sabbatical until February 2018, but you may search the forum for posts he wrote around the date of the commit. If that’s a change that resulted from a discussion happened here in the forum, you may find there the answer you seek.


#9

@LukeM1 a quick search of @fabian’s forum posts by date revealed a response to this on the same day as the commit…


#10

The VST3 SDK has a conceptual separation between the Editor and the Processor, and looking at the AGain example in the SDK you can see that EditController::setParamNormalized is only responsible for updating values in the editor, and the equivalent of JuceVST3Component::processParameterChanges is only responsible for updating the values in the processor.

This is why it is breaking with JUCE, because they are both being directed to the same place: AudioProcessorParameter, hence the wobbling effect during playback where the two mechanisms are fighting each other.

So if we want to keep the fix above (for the editor updating when not playing back), it will have to change slightly. The only way I can think of right now is to check the playback status in Param::setNormalized and only let the values through when not playing, basically toggling which mechanism is in charge of pushing values in to the plug-in. I’ve tested this very briefly and it seems to fix both issues, although it seems like calling PlayHead::getCurrentPosition in that method will be quite inefficient, so perhaps there’s an easier way?

I’ve attached a patch which implements the above suggestion to avoid any confusion.

0001-VST3-AUTOMATION.txt (1.3 KB)


#11

@jules, @t0m, @ed95, I think someone from the JUCE team should probably take a look at this when you can, it’s actually a pretty nasty bug.

I’ll try and put together a little video showing the problem in action if it helps. The easiest way to replicate it for yourself is to create a plugin with a large rotary (making the control large just makes it easier to see the issue). Draw in some automation (a slow ramp from 0 to 1 should do it), and play it back with the GUI open. The control will appear to flicker between values as it gradually ramps up.


#12

Fixed here:

https://github.com/WeAreROLI/JUCE/commit/2d9231111699b6ead3df922b07a95eec9db4c114


#13

Thanks @t0m!


#14

@t0m Sorry to bother you for a 2nd time today. Would it be a problem to cherry-pick this to master?


#15

Done.

It’ll appear in 15 minutes or so.


#16

Thanks a lot, @t0m!