The Cockos ReaPlugs standalones(*) have at least one problem with the Juce VST2 hosting code. When certain things are manipulated in them, such as the spectral response editor in ReaFIR, the Juce plugin hosting/AudioProcessor code will assert in debug builds. This is because the plugins call a parameter change with parameter index -1, which the Juce code considers an error worth an assert.
I did my own ugly hack in the Juce AudioProcessor code to deal with this, but I wonder if there could be some cleaner solution…Preferably these parameter -1 notifications from the plugins should cause the AudioProcessorListeners of the AudioProcessor to be notified. (For purposes of undo history, invalidating offline render caches etc…)
Unfortunately the assertion is valid since the plugin is sending an out of range index. Once you build the project in release mode you won’t encounter this breakpoint anymore – the asserts are just for debugging purposes.
You could report the bug to the Cockos ReaPlugs people if you wish!
Is it definitely mentioned in the VST2 “standard” that the plugins are not allowed to make negative parameter index change calls into the host? If it is mentioned as such, is there then any way for the plugins to send a change notification to the host that tells “something changed but it wasn’t an automatable parameter”?
In a JUCE plugin you would call updateHostDisplay(), this calls audioProcessorChanged() in the VST2 wrapper which in turn calls setInitialDelay(), updateDisplay(), and ioChanged() (called asynchronously).
OK, I guess I have to try to persuade the Cockos developer to change that eventually. In the meantime I’ll just bypass checking for the assert based on the AudioProcessor’s name in my Juce version.
