Hosting Waves plugins asserts

Audio Plugins
1

When loading Waves instruments, like Bass Fingers or Element, a few asserts are thrown. The plugins keep on loading correctly after that.

This happens in AudioPluginHost on latest develop and latest Waves plugins.

Any ideas how to stop this from happening?

The assert that’s thrown is in:

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

Please can you add the plugin formats and platforms where you see the issue?

3

Ah, sorry about that! VST3. Mac M1/Ventura

4

I had a quick look into this. I think the assertions are valid - these plugins are requesting an input bus that should be active by default, but should have no channels. This seems a bit weird to me… It’s not clear to me whether this is allowed under the VST3 spec (it passes the “official” validator, so it seem to be OK), but I’m not sure why an empty, active bus would ever be desirable.

I think these assertions should stay. It’s useful to know that the plugin is doing something a bit unusual when testing a custom VST3 in the AudioPluginHost.

The other assertion I see is a request from the plugin to open the editor. We don’t have a way of surfacing this request through the JUCE API at the moment, and I’m less sure that this assertion is valuable, so perhaps we should remove this one.

5

Thank you for checking that!

I don’t know enough about the VST3 specs in this case, it’s just strange to me that a plugin that loads correctly in most/all hosts (AFAIK) is asserting.

Do you think this is a problem I should be reporting to Waves?

6

It definitely seems a bit strange. If nothing else, it’d be interesting to hear whether this is intentional, and why an empty bus is preferable to a disabled bus in that case.

1 Like