Multiple questions about sidechain-plugin builds

hi. i started a plugin project with the projucer and now i have several questions. let me show you my thought process:

i added a 2nd input as my sidechain input like this:

MoodiplyAudioProcessor::MoodiplyAudioProcessor() :
                        .withInput("Input",  juce::AudioChannelSet::stereo(), true)
                        .withOutput ("Output", juce::AudioChannelSet::stereo(), true)
                        .withInput("SC", juce::AudioChannelSet::stereo(), false)

then i defined the busses-layout as following:

const auto mono = juce::AudioChannelSet::mono();
const auto stereo = juce::AudioChannelSet::stereo();
if (layouts.getMainOutputChannelSet() != mono
   && layouts.getMainOutputChannelSet() != stereo)
      return false;
if (layouts.getMainOutputChannelSet() != layouts.getMainInputChannelSet())
   return false;

return true;

it builds as a plugin (yay), but when i try to run it in standalone mode i run into an assert:

usually JUCE’ asserts are documented very well in the comments, but this one just says that the “arrangement” is not supported by the processor without telling me why or what to do about it.
so my most important question is:

Is it possible at all to run a plugin project with a sidechain input as a standalone build?
if yes: what have i done wrong (and why)?
if no: what is the default solution to get around this? at some point i wanna debug GUI-aspects without being hold back by long build times that have to run a DAW.

(by the way, feature request: add a build type to the default plugin project of the projucer that acts just the same as the VST3-Build, but with JUCE’ built in plugin host as a debugger at all times, so one can use the VST3-Mode to debug in an actual DAW without having to switch away from the test host.)

Now there is also another little question, a bit unrelated, but if anyone knows i’d appreciate an answer:
Can a plugin have multiple sidechain inputs?
If yes: Nice! Does it require any extra steps?
If not quite: Which DAWs support it and which don’t?
If no: Boo, what a shame. we need a better plugin standard! ( Opportunity for CLAP? :wink: )

I don’t really remember how I wound up getting this to work (and am not exactly an expert with handling channel configurations correctly), but I did something similar (albeit with a mono sidechain and without the isActivatedByDefault flags specified) and overrode isBusesLayoutSupported with

bool AudioProcessor::isBusesLayoutSupported(const BusesLayout& l) const
	return (l.getMainInputChannelSet() == l.getMainOutputChannelSet() &&

and it seems to work for doing debugging (but JUCE would need a more sophisticated I/O configuration system to actually be able to test the sidechain in standalone mode), and I’m able to get sidechain signals sent into it within Ableton.

thx! i tried to use the default arg of activation in the constructor and tried replacing my lines of code with yours, and combinations of these, but unfortunately i still get the same assert. but it’s good to know that it can actually work. that means i’m still just missing something

Another thing I forgot to add: if you’re using a custom i/o configuration like this case, you also need to remove any “Plugin Channel Configurations” that might have been set within the Projucer’s settings.

Also, changing your audio device in the standalone configuration window when debugging might also fix some things, as well as possibly even removing the .settings file that’s generated by the standalone application and placed inside your “special location” folder, as it contains XML data that the plugin uses to restore it’s previously used audio device settings (and you could re-configure it from there).

1 Like

good idea. i need to try that. i’m actually not sure if it ever ran as standalone before but if it did there must be a .settings file