AU plugin shows wrong number of input channels in Ableton Live

Hello!
I am using JUCE v6.0.8 and Ableton Live 11. When I add my plugin to a track I see that the number of input channels is read as 9, even though the track is stereo. This only happens in AU format in Ableton Live, all the other formats and DAWs show up the correct number, 2. I tried it with an empty project and added some debug messages:

getTotalNumInputChannels() = 9
layouts.getMainInputChannels() = 9

This doesn’t happen with JUCE v6.0.4.

I’ve noticed this too. Multi-channel capable JUCE AU plugins will show up with too many channels in Live even if the bus is configured to stereo.

What I don’t know is whether this is a bug in JUCE or in Live? It doesn’t happen in other hosts so I suspect this is a Live bug?

It is definitely a JUCE bug. I get the same 9 channel configuration in Ableton Live 10 with JUCE v6.0.8. And everything works fine with Ableton Live (10 and 11) when using JUCE v6.0.4.

Howdy all. Just moved from JUCE 6.0.1 to JUCE 6.0.8 and have been encountering the same issue. Did you ever resolve your problem, and if so, by golly would you care to share ?!?! Thanks!!

Please can you let us know how you’re configuring the buses? What does your implementation of isBusesLayoutSupported look like? Are you using JucePlugin_PreferredChannelConfigurations, and if so, what value are you using?

Howdy Reuk,

we are using isBusesLayoutSupported as shown below … yikes hope this does not look too gross in the thread !! …

bool isBusesLayoutSupported (const BusesLayout& layouts) const override
{
    // the sidechain can take any layout, the main bus needs to be the same on the input and output
    // (this will prevent mono to stereo configuration allocation)
    return (layouts.getMainInputChannelSet() == layouts.getMainOutputChannelSet()) &&
    !(layouts.getMainInputChannelSet().isDisabled());
}

… do we need to be limiting the number of input and output channels here as well ? If so how ?

… we also do this … the constructor for AudioProcessor is the same as delivered, but we optionally add a side chain (mono or stereo) for certain plug-ins … I thought this would limit the number of channels we are willing to accept to mono and stereo. Is that not correct ?

AudioProcessor::AudioProcessor()
#ifdef MCDSP_HAS_SIDECHAIN
: AudioProcessor (BusesProperties().withInput (“Input”, AudioChannelSet::stereo(), false)
.withOutput (“Output”, AudioChannelSet::stereo(), false)
.withInput (“Sidechain”, AudioChannelSet::stereo(), false))
#else
: AudioProcessor (BusesProperties().withInput (“Input”, AudioChannelSet::stereo(), false)
.withOutput (“Output”, AudioChannelSet::stereo(), false))
#endif
{
}

Howdy again

I am also able to observe the issue no longer occurs when I compile with JUCE 6.1.5. But I would sure like to know if my implementation of isBusesLayoutSupported() needs an adjustment. Thanks !!

For the record, it looks like the old behaviour was fixed in this commit:

I think that the implementation of isBusesLayoutSupported looks reasonable, assuming that any number of channels is valid on the main input bus. If your plugin won’t cope with lots of channels then you should probably check the channel count too, e.g. layouts.getMainInputChannelSet().size() < maxChannels.

It looks like your default bus properties, passed to the AudioProcessor constructor, disable all buses by default. At the moment, your implementation of isBusesLayoutSupported will return false for the default layout you’ve requested, because the default layout has a disabled main input bus.

I’d strongly suggest changing the default bus layout so that the main input and output buses are enabled by default.

Reuk,

I see the fix link - thank you. I see the change date of June 24, 2021 … so this was a fix provided after the JUCE 6.0.8 SDK release, and in fact looks like its only in JUCE 6.1.x releases, yes? How do I keep myself updated on such changes (within reason !!!) ? Or is it best to move on to later official JUCE releases?

Regarding checking channel count maximum in isBusesLayoutSupported(), that sounds like a fine idea. But is that were I do such limits, or do I specify maximum channel count elsewhere like in getMaxSupportedChannels() ?

Regarding the disabling of all buses by default … that is what AudioProcessor does in the JUCE SDK as delivered, so I did not think I should change that. Did I screw something else up in isBusesLayoutSupported() that would have otherwise made disabling all buses the correct implementation, as given in the SDK? I just want to make sure I am not making any other mistakes.

Thanks for your time in responding to this thread.

It sounds like you’re mostly happy with JUCE 6.0.8, so you personally may not find much advantage in updating regularly. However, if you do discover any bugs in the old version of JUCE, it’s always a good idea to try reproducing the issue using the develop branch before reporting it, as there’s a reasonable chance that the issue will already have been fixed on develop.

Additionally, it’s normally a good idea to update JUCE shortly after new operating system versions are released. We often merge compatibility improvements when there are new versions of macOS, for example.

Yep, isBusesLayoutSupported is a good place for those checks.

This works because the default implementation of isBusesLayoutSupported just returns true. My suggestion is that isBusesLayoutSupported should always return true for the plugin’s default layout. Given that your isBusesLayoutSupported function requires that the main bus is enabled (which is sensible if the plugin requires audio i/o!), the default layout should have an enabled main bus.

Hope that helps!