AudioProcessorPlayer and plugins with unusual channel configs

Audio Plugins
1

I have a 3rd party VST plugin with 2 ins and 8 outs that I'd like to use with an AudioProcessorPlayer. When setting the plugin as the player's processor, we have

void AudioProcessorPlayer::setProcessor (AudioProcessor* const processorToPlay)
{
    if (processor != processorToPlay)
    {
        if (processorToPlay != nullptr && sampleRate > 0 && blockSize > 0)
        {
            processorToPlay->setPlayConfigDetails (numInputChans, numOutputChans, sampleRate, blockSize);
            processorToPlay->prepareToPlay (sampleRate, blockSize);
        }

...

    }
...
}

where numInputChans/numOutputChans are taken from the audio device, so typically 2 for both of them. However, it seems from

void AudioProcessor::setPlayConfigDetails (const int newNumIns,
                                           const int newNumOuts,
                                           const double newSampleRate,
                                           const int newBlockSize) noexcept
{
    sampleRate = newSampleRate;
    blockSize  = newBlockSize;

    if (numInputChannels != newNumIns || numOutputChannels != newNumOuts)
    {
        numInputChannels  = newNumIns;
        numOutputChannels = newNumOuts;

        numChannelsChanged();
    }
}

 

that the info about the number of input/output channels never makes it to the plugin since numChannelsChanged() is a virtual function that is not implemented in VSTPluginFormat. So what happens is that the plugins happily tries to fill all of its 8 output channels ---> crash.

I'd suggest to either implement numChannelsChanged in the plugin format or, in AudioProcessorPlayer, not to use a buffer with the audio device's channel configuration but with the processor's default channel configuration (i.e. dummy channels if needed).

 

2

*bump*

3

If I understand you correctly, I'm not sure what you'd expect the VST wrapper to do if you ask it to render into a number of channels that the plugin itself doesn't support?

4

Hmm, that's the opposite case... but that can already happen now, can't it? Say the device manager wants two channels, so the plugin is given two float arrays. If it's a mono plugin, it will only fill the first one and leave the other one untouched. What I referred to was the case where the plugin tries to fill more channels than it is given in processBlock().

 

5

AudioProcessor::getNumInputChannels is there to tell the caller how many channels it needs, and the VST wrapper will return the number of channels the VST needs. If you override that with some other number and start feeding it too many or too few, then yes, it'll probably crash.

6

I think there's still some misunderstanding, sorry if I'm not being clear enough: I am loading an external dll, which was not compiled by me, therefore I do also not override getNumInputChannels(), I just let the pluginFormatManager create an instance of a plugin from a file on disk. This AudioPluginInstance is given to an AudioProcessorPlayer. My point is that the AudioProcessorPlayer never asks the plugin how many channels it can handle but instead just hands over the number of channels that the AudioDeviceManager (which is calling the AudioProcessorPlayer for data) wants to have.

Or is there some fundamental error that I'm making in using the AudioProcessorPlayer class like this?

7

Well, I guess that's an issue with the AudioProcessorPlayer not being smart enough. AudioProcessors aren't expected to be able to cope with unusual sets of channels, so the caller needs to be the one that's responsible for giving it the appropriate buffers. Will look into it at some point..