JUCE channel mapping

1

In processBlock, is it possible to get access to AudioSampleBuffer with the original channel order, as provided by the host and without any remapping by JUCE ?

I cannot find a simple way to figure out JUCE mapping and reverse it.

Thanks

2

I don’t know about the original, but to know which channel is what, you use the Bus infrastructure:

  1. getBus (true, 0) to get the main input bus
  2. getCurrentLayout() to get the AudioChannelSet
  3. use getTypeOfChannel(i) or getChannelIndexForType() to understand the channels
if (auto* bus = getBus (true, 0))
    auto leftIndex = bus->getChannelIndexForType (juce::AudioChannelSet::left);
1 Like
3

Thanks for the tip. Ideally I’d just bypass JUCE reordering and get the raw buffer as provided by the host. @reuk is there any way to do that ?
Thanks

4

No, that’s not possible at the moment.

5

The current automatic mapping is sometimes problematic. For example in Reaper, a 7.1 file (L R C Lfe Ls Rs Sl Sr) is automatically remapped to (L R C Lfe Sl Sr Ls Rs). This happens with JUCE VST3 wrapper only, not VST2…
Since it is hard (if not impossible) to predict channel orders of all tracks/wavfiles, we let users choose their input format directly in the plugin. That’s why we’d need to bypass JUCE mapping, or at least know what mapping was applied (to potentially reverse it).

6

Would you have any tip for bypassing channel remapping in the VST3 wrapper ? Is it something that could be officially supported in the future ?
Thanks

1 Like
7

This is something I’m coming up against as well, particularly in Reaper.

The JUCE remapping is fine when you know the plugin is loaded in a DAW that is explicit about the bus type. Reaper just lets you set channel numbers and tends to use the default bus layout. Therefore, a 12 channel track leads to a 7.1.4 plugin and the channels get remapped. That’s fine if the original track was 7.1.4 but if it was any other format of 12-channel file then the mapping is no longer correct and needs accounted for.

Some sort of bypass would be great. At least the option to get the remapping. It’s in the VST3 wrapped so is there a way to access it from AudioProcessor?

8

I’ve been looking at this a bit more and, while disabling the remapping would be ideal, it should be possible to reuse the JUCE remapping itself. ChannelMapping in juce_VST3Common.h should give enough to write a simple “mapping-undo” class to use in an AudioProcessor.

The problem I’m running into is that if I use #include <juce_audio_processors/format_types/juce_VST3Headers.h> and #include <juce_audio_processors/format_types/juce_VST3Common.h> I get a lot of compiler errors. It seems that we can’t include juce_VST3Headers.h again.

Is something I’m missing to be able access ChannelMapping from elsewhere in my code? Thanks :slight_smile: