Hi we’ve found a bug that has cropped up in a couple of our plugins when upgrading to Juce 7 - occurs in 7.0.2 and develop, does not occur with Juce 6. Only been able to test on mac so far, win status unknown.
It happens when you have a call to setLatencySamples(> 0) in prepareToPlay() {…} with VST3 in Wavelab 11. To quickly test you can just add setLatencySamples(1000); to prepareToPlay() in NoiseGatePluginDemo.h.
To recreate:
Open Wavelab, do not start transport
Load audio file
Add the JUCE plugin to the master effects
Start transport
You then get the following error, and the plugin is disabled:
If you instantiate plugin after transport has begun, the plugin works, but if you then close Wavelab and reopen the same file, the plugin will auto-load broken again.
Thanks for checking! For me there was no problem finding and instantiating the plugin manually. It’s just when wavelab automatically reloads the plugin when you open a project before you’ve ever hit transport. It loads and the UI opens etc, but starting transport causes an error and the plugin doesn’t function.
Yeah I saved and reopened the project and the plugin opens and functions correctly when I hit the spacebar to start playback.
Before when I was using JUCE 6.1.6 for the same plugin – I saw the same issue you reported when instantiating the plugin (which is mono/stereo with a sidechain input).
BTW the error was being caused because in
void processAudio (AudioBuffer<FloatType>& buffer, MidiBuffer& midiMessages,
Vst::SymbolicSampleSizes sampleSize, bool isProcessBlockBypassedCall)
{
using namespace Vst;
auto numSamples = buffer.getNumSamples();
auto numInputAudioBuses = getBusCount (true);
auto numOutputAudioBuses = getBusCount (false);
the numInputAudioBuses was wrong.
Since switching to JUCE 7 fixed it for me I stopped looking for the cause.
Ah interesting thanks… The cause for me is calling setLatencySamples() in prepareToPlay, so it might be a slightly different bug but with the same symptoms in Wavelab.
