Possible demo plugin bug


#1

I have found some buggy behaviour in the preset loading of the JUCE demo plugin when writing automation in Cubase.

Problem:
Writing automation by switching presets doesn’t work as expected (tested in Cubase on Windows)

Recipe:

  • Load plugin onto a track
  • Save two presets (for example one with all minimum values, and another with all maximum values)
  • Set the track to write mode for automation
  • Start playback
  • Toggle between presets

What happens:
The first preset switch appears to change the data from the beginning of playback rather than from the point it was actually changed.

What should happen:
The first preset switch should be recorded at the time the change actually occurred. (Confirmed with built-in plugins and the aGain VST3 SDK example plugin)

The solution:
Change the call from setValueNotifyingHost() to setValue() in setStateInformation().

As far as I can tell so far, hosts (tested with Cubase and ProTools) should call getParameter() after calling setStateInformation() (makes sense!). However is anyone aware of any hosts that do not behave like this?


#2

Thanks for the heads up, sounds like a sensible fix. But I’d also like to know if anybody knows of hosts that require the setValueNotifyingHost in she setStateInformation. Also remember that this needs to not only work for VST3 but all the other plug-in formats.


#3

Also remember that this needs to not only work for VST3 but all the other plug-in formats.

Absolutely we will try and get some testing done in lots of DAWs and formats, on at least OS X and Windows.


#4

To clarify, here is some additional information:

  • Behaviour without changes to the JuceDemoPlugin project is consistent in VST2 and VST3. The first state load does not get recorded as a change from the initial state to the loaded one, instead the automation tracks are written as if the record began in the loaded state (see attached images).

  • Aforementioned fix only fixes the behaviour in VST2 (changing the setValueNotifyingHost() call in setStateInformation() to setValue()).

  • In comparison of JuceDemoPlugin and AGain VST3 projects, it is evident that AGain does not call performEdit() when updating parameter values during a state load, whereas JuceDemoPlugin does (in audioProcessorParameterChanged()). However, preventing a call to performEdit() in JuceDemoPlugin results in no automation being written at all, which begs the question: how is AGain writing automation when the host is not informed of any edits?

AGainVST3
JuceDemoPlugin (VST3)

JuceDemoPlugin built with JUCE v4.2.4.
VST3 SDK version: 3.6.5.
Tested on Windows 10, using Cubase v8.5.15.


#5

OK I think I fixed this on the develop branch. Please test!


#6

Thanks for the quick response!

Unfortunately this hasn’t fixed the problems in VST3. Behaviour is the same as demonstrated by the images in my last post.

Are you able to reproduce the issue in-house?


#7

Yes I was able to reproduce it and my recent commit does fix the issue - also for VST3. Are you sure you are now calling setValue instead of setValueNotifyingHost in your setStateInformation callback. See the change I did to the JuceDemoPlugin.


#8

Oops! Build wasn’t copied over to the plug-in directory…

I can confirm the fix does work on Windows 10 and OS X 10.11.5 both using Cubase 8.5.

Thanks Fab.


#9

@fabian it appears to work and hopefully we don’t find any issues in other hosts but I’ve also noticed that in setComponentState() you are returning Vst::EditController::setComponentState (stream); which in turn returns kNotImplemented, should you not be returning kResultOk here?


#10

That is intended. I can’t remember why but some DAWs needed that.


#11

That’s very peculiar, someone should probably let those hosts know that they are probably doing it wrong! The aGain plugin returns kResultOk. I’ve noticed that in the past as an industry we (plugin developers) have tended to fix/hack things to keep hosts happy when we should all make an effort to reach out to host developers to inform them that there is unexpected behaviour occurring in their DAW.

Anyway thanks again for the speedy fix.