Working on a plug-in that contains an AudioProcessorGraph and of course AudioGraphIOProcessors to get Audio in and out of the graph. If the plug-in is an effect things work as expected but I encountered some strange behaviour when I changed the plug-in to be a synth. I found that the graph’s output node did not have any inputs (it was triggering an assertion). On close inspection of the AudioProcessor class it seems there are 16 #ifdef statements in the constructor that refer to plug-ins, and because this audio processor was inside a synth plug-in its buses were affected by the global #ifdef JucePlugin_IsSynth.
I think it would be much better if AudioProcessor did not use plugin related #ifdefs like this, which assumes any AudioProcessor in a plugin is always a plugin’s main AudioProcessor. Perhaps these options could be passed in as arguments to the constructor instead - with sensible defaults?
I agree, I posted a few days ago with the same issue. When using a processor with some subprocessors inside it (like a synth, with some effects), all the effects ins/outs now get messed up.
The stuff in there is just a fallback to maintain compatibility with pre-multibus code. We’ll remove it all eventually when everyone has had time to update their bus configuration code.
DISCLAIMER: If your plug-in does not require sidechain inputs or aux outputs or does not depend on the exact layout of the audio channels (i.e. your plug-in does not care if six channel audio is 5.1 surround, 6.0 surround or hexagonal audio) then it is easiest to use the PlugIn Channel Configuration field in the Introjucer.
The multibus guide doesn’t state anywere that we should update our code if we are not using multiple busses. On the contrary, it tells to use the old #defines for all projects with simple bus layouts.
I think you should change the wording if you want to encourage people to make the transition.
