VST3 host issue - Windows

Audio Plugins
1

Hi Folks,

I’m testing out the JUCE Host capability on Windows - using some commercial VST3 units I purchased from waves dot com.

NB: My host code works fine with macOS/iOS and AUv3.

I’m finding that having called this:

VST3PluginFormat::createPluginInstance

then, when in here:

static AudioProcessor::BusesProperties getBusProperties (VSTComSmartPtr<Vst::IComponent>& component)

This returns 1:

const int numBuses = component->getBusCount (Vst::kAudio, dir);

And the subsequent call here:

if (component->getBusInfo (Vst::kAudio, dir, (Steinberg::int32) i, info) != kResultOk)

populates the info structure with channels = 0 …!

The subsequent call here is made:

busProperties.addBus (isInput, toString (info.name), layout,
                                      (info.flags & Vst::BusInfo::kDefaultActive) != 0);

And this leads to a failure on this assertion:

void AudioProcessor::BusesProperties::addBus (bool isInput, const String& name,
                                              const AudioChannelSet& dfltLayout, bool isActivatedByDefault)
{
    jassert (dfltLayout.size() != 0);

Has anybody got any suggestions? This has me completely stumped!

Best wishes,

Pete

2

NB as an experiment I just installed Fab Filter One (from a different vendor…) … and that doesn’t suffer from the same assertion. It suffers from a later assertion - but one step at a time :slight_smile:

Pete

3

FWIW, I also get jassert calls when initialising Wave Elements Stereo VST3 when using the AudioPluginHost.

I should note that I get this error at least once when trying to show the UI for the Waves Element Stereo VST3 from the AudioPluginHost demo for Windows:

warnOnFailure (view->attached ((void*) pluginHandle, defaultVST3WindowType))

Fab Filter One shows no issues with the AudioPluginHost.

So, this shows:

  • there is a generic issue with JUCE and/or the Waves VST3 I’ve looked at
  • there is something wrong with my code, that affects Fab Filter One!
4

For those who are interested, I’ve figured-out the issue with Fab Filter One, by changing the code around it to work like this:

  juce::MessageManager::callAsync ([=] {
    // Create the plug-in here!
  });

The assertions with the Waves plug-ins remain, but otherwise the Waves plug-ins seem to work.

Pete

5

You might want to look at enableAllBuses(), not create a new bus.

1 Like
6

Hi @jim777,

Thanks for the tip! However, this happens in the JUCE plug-in initialisation code, before I actually do any of my own configuration. I hope the JUCE devs will try out a free Plug-in download from waves and take a look; I have to presume the jassert call in question isn’t important in this case…!

Pete

7

Do you see the same assertion in the AudioPluginHost?

8

Hi @reuk yeah, I did. I only saw it with the waves plug-ins, so at least then I realised it wasn’t my app causing the problem :slight_smile:

Best wishes, Pete

9

I’ve now tried out loading Elements Stereo VST3 in the AudioPluginHost on Windows. I see that it hits two assertions when starting up, because it requests a main input bus with no channels.

This particular code (AudioProcessor, AudioProcessor::Bus) is used by both plugin hosts and clients, but I suspect the assertions are designed to discourage plugin clients from requesting buses with no channels. In a plugin host, the assertions may not indicate a dangerous failure, so they’re probably benign. Indeed, if I continue past the assertions, Element seems to work as intended.

1 Like
10

Hi @reuk thanks for giving this a go. Yes, that matches what I saw. Is there something you could replace jassert with, maybe a benign jwarn that doesn’t kick-in the debugger? Pete

11

I think this is unlikely. The assertion is useful for plugin clients, but we don’t have a way to check whether the AudioProcessor is being used in a host/client context (some plugin projects might have internal hosting support).

12

OK, fair enough :slight_smile: Pete