Number of channels in the buffer, sidechain, VST3, JUCE 7

naima · June 25, 2022, 10:44pm

Hi, I’ve been working a copule of month ago in a plugin with gen~ and JUCE 6, It has busses properties stereo in/out + stereo sidechain bus for AU and VST3, and mono sidechain bus for AAX. I’m using Reaper in debug mode for AU and VST3 and it seems apparently to work fine at compile and runtime, also AAX looks good in PT (appart from I can’t attach it to Xcode).

Now I’m trying the same code with JUCE 7 (and lastest v6 master branch commit); AU and AAX works fine, but with VST3 something different is happening related to the total number of channels that appears in the buffer, the strange thing is that If I run it with an already opened Reaper project with the plugin already inserted the number of channels of the buffer seems to be ok: 4 (2 main + 2 sc), but when opening a new instance of the plugin it shows only 2 channels (main) in the buffer, also I hit some jassert related to the number of channels in getRMSLevel for the SC meters…

If I go back and run with the previous (april or so) version of JUCE 6 everything works again, and the total number of channels in the buffer is always 4.

Any idea? thank you.
jc

Already running instance in a regular stereo channel in Reaper, JUCE 6/7:

Loading a new instance in a regular stereo channel in Reaper, JUCE 7

mrotschi · June 27, 2022, 9:58am

Hi @naima,
I think this is related to that change:

github.com/juce-framework/JUCE

VST3 Client: Allow host to enable/disable buses at will

committed 02:29PM - 13 Jun 22 UTC

reuk

+656 -373

Previously, activateBus would fail if the new BusesLayout wasn't supported, as r…eported by isBusesLayoutSupported. However, according to the VST3 docs, a host is allowed to enable and disable buses in any combination, and the plugin should be able to handle this gracefully. The ability to enable/disable individual buses without failure is particularly important because there's no VST3 API to set a complete bus layout in one go. That is, the only way to set all buses active or all buses inactive is to set the appropriate state on each bus individually, which in turn means that at some point, some buses will be active and some will be inactive. Disallowing such 'intermediate' states may prevent the host from putting the plugin into other (valid) states. To ensure that the VST3 wrapper always accepts activateBus calls, it now keeps track of the activation state of each bus as requested by the host. When the host tries to change the activation state, the wrapper will try to set the host's "ideal" bus layout on the AudioProcessor. If this fails, the AudioProcessor will retain its previous bus layout. The buffer remapping inside the process callback has been made more robust, to handle cases where the host and the AudioProcessor disagree about the activation state of each bus: For input buses: - If the host has activated the bus, but the AudioProcessor decided to keep the bus inactive, the host's input will be ignored. - If the host deactivated the bus, but the AudioProcessor wanted to keep the bus active, the AudioProcessor will be provided with silence on that bus. For output buses: - If the host has activated the bus, but the AudioProcessor decided to keep the bus inactive, the wrapper will clear the host's output bus buffers. - If the host deactivated the bus, but the AudioProcessor wanted to keep the bus active, the AudioProcessor's output on that bus will be ignored. The AudioBuffer passed to the wrapped AudioProcessor will no longer contain any pointers from the host's ProcessData. Instead, the host's inputs will be copied (in JUCE channel order) to a temporary buffer, and this temporary buffer will be passed to AudioProcessor::processBlock. After processBlock, the buffer contents will be copied to the host's output buffers. This change is intended to avoid a potential issue when reordering channels into JUCE order, which may necessitate copying a host input channel to a different host output channel. In the case that the host is using the same buffers for both inputs and outputs, copying an input to an output channel may end up overwriting another input channel, breaking the plugin's inputs.

(I am not sure of the changes that need to be made on the plugin side though…)

naima · June 27, 2022, 10:48am

Oh thank you!! this seems to be, will look into it

RolandMR · June 27, 2022, 1:29pm

Since upgrading to JUCE 7 I’m hitting this assert. My channel config is set to {0,1}

jassert (arr.inputBuses. size() == getBusCount (true) && arr.outputBuses.size() == getBusCount (false));

naima · June 27, 2022, 7:12pm

I did some test and it seems to me that other VST3 plugins with ext sidechain inputs shows a similar behavior than my plugin in Reaper: in order to use the sidechain inputs I’ve either to specify additional “track channels” or refresh the “VST3 bus size” (wich defaults to auto). So if possible how can I request to Reaper the “VST3 bus size” of 4 when loading the plugin?

vst3. bus size

track ch

Number of channels in the buffer, sidechain, VST3, JUCE 7

Purchase

Discover

Learn

Support

About

Events