VST3 stereo only plugin in Cubase Mono channel - probable Juce bug


#1

Hello everyone,

i am developing a plugin which does not support pure mono. So Cubase is loading a stereo version of it into the mono channel. Audio is fed only into the left plugin input and taken only from the left plugin output.

Now what I experience is that this works for VST but as a VST3 plugin the buffer on the (unused) right plugin channel is not flushed by Cubase/VST3/JUCE (don’t really know which one is the culprit). So audio is accumulating on the right plugin channel which due to the plugins algorithm also gets output on the left plugin channel.

Below you find a test plugin to demonstrate. The jucer file you just need to rename back from .jucer.txt to .jucer

Any idea what to do about it?

Best,

Thomas

PluginProcessor.cpp (5.6 KB)
PluginEditor.h (1.0 KB)
PluginProcessor.h (2.2 KB)
PluginEditor.cpp (1.3 KB)

vst3test.jucer.txt (4.4 KB)


#2

Ah, I just forgot to mention, the problem occured on Mac, on Win I havent tested it yet…


#3

Windows the same …


#4

We have just tested it with a plugin not based on Juce, but using the same VST3 SDK (3.6.7) and the problem did not occur. Therefore I can assume with a high probability that the bug is hidden somewhere in Juce. I haven’t been able to locate it yet.

Help would be greatly appreciated since we are already in beta and this bug is observed on Cubase and Nuendo, Mac and Win, with VST3 only. As said before, VST does not show this behaviour.

Best,
Thomas


#6

Can you tell me please what is the problem? In my code it just sums the two channels and outputs it on both.

Apart from this, the process block is the same for both VST and VST3.


#7

The isBusLayoutSupported requests the output to be the same as the input:

// This checks if the input layout matches the output layout
#if ! JucePlugin_IsSynth
if (layouts.getMainOutputChannelSet() != layouts.getMainInputChannelSet())
    return false;
#endif

So Cubase shouldn’t be able to run this plugin on a mono track. But I think that is the reason, why the clear command does not kick in:

for (int i = totalNumInputChannels; i < totalNumOutputChannels; ++i)
    buffer.clear (i, 0, buffer.getNumSamples());

Maybe print debug the values of

const int totalNumInputChannels  = getTotalNumInputChannels();
const int totalNumOutputChannels = getTotalNumOutputChannels();

to understand, what the actual configuration is.

If you want to support mono to stereo, you will have to get rid of the mentioned if .. return false statement in isBusLayoutSupported

Also instead of clearing the first channel you could do

if (totalNumInputChannels > 0)
    for (int i = totalNumInputChannels; i < totalNumOutputChannels; ++i)
        buffer.copyFrom (i, 0, buffer.getReadPointer (i % totalNumInputChannels), buffer.getNumSamples());
else
    buffer.clear (0, buffer.getNumSamples());

which would copy the content of the input channels to the channels with no data, and runs very optimised as SIMD instruction on the processor (if available, which is the case on most processors past year 2000)


#8

Hi Daniel, thanks for your explanation.

Unfortunately you did not hit the point :).

First of all, if you look at the jucer project, you see that i explicitly defined the only allowed channel config to be {2,2}, eg stereo in, stereo out. So the isBusLayoutSupported() will not be called, because of the #ifndef JucePlugin_PreferredChannelConfigurations.

Second i replaced the String “Hello World.” in the plugin GUI with something that shows me the actual channel config. You should see “2-2”.

Third, the test plugin which is not based on juce, was also loaded as a stereo in stereo out plugin on a mono channel so I suppose that Cubase does this intentionally.

And fourth, as I wrote before, with VST there is no problem, only with VST3. So it does not make much sense to look at my code, since it is independent of the used plugin format.

Anyway thanks for having a look.

Best Thomas


#9

Ah, forgive me, I haven’t seen the macro.

So if your code get’s notified, that it has two input channels, then it does the right thing.
Then it might be Cubase’s fault, to allow that plugin on a mono track at all. And if it does, one would expect to copy the content for you…

Did you check with a different VST3 host?

I didn’t, because I don’t have Cubase, so forgive me, that I didn’t run your code…


#10

Hi Daniel,

nothing to forgive. :wink:

Yes I checked with other hosts. Nuendo shows the same behaviour, which is no wonder. But elsewhere the plugin does not get loaded on a mono channel, if there even exists a mono channel. But i also did not check all available hosts.

Thanks for looking at it though,

Best,

Thomas

EDIT: Just checked with Studio One. It also loads the stereo plugin onto a mono channel but sends the signal to both plugin inputs. So no problem…


#11

@Thomas_Fiedler this might be one of those oddities requires special treatment cases for special hosts.

If you never expect silence you can check if one channel buffer is zeroed and workaround it.
You can also detect hosts and limit your workaround(s) to those hosts.

I know this isn’t the nice way of doing things but each hosts has bugs and differences and even when bugs are fixed, not all users update their DAW…


#12

Hi ttg,

yeah I am thinking of work arounds. But since the test with the non Juce based plugin worked while the Juce based plugin had the problem, I think the solution must be found in Juce.

About the content of the input buffer I don’t like to assume anything…

Best,

Thomas


#13

Hi Guys,

so i just checked with the again plugin of the VST3 SDK. I only modified it in the way that it can only be loaded as a stereo plugin and that it does the same as my example plugin above (summing both channels and outputting the result to both). The error did not occur. So I am more sure now that the bug must be somewhere in Juce.

@jules, @fabian etc.: Please have a look at it soon. It is currently blocking beta.

Best,

Thomas


#14

Thanks for reporting @Thomas_Fiedler and thank you everyone for there contribution on this report.

This is now fixed with this commit.


#15

Great! Thanks. I will soon test it.


#16

Hey @fabian ,

it seems to work. Thanks for the quick fix.

Best,

Thomas