MultiBus crash with REAPER + other bugs


#1

Hi, I'm using the new bus system in order to mimic previous the previous pluginChannelConfigs: {1, 4}, {2, 4}, {3, 4}, {4, 4}, {5, 4}, {6, 4}, {7, 4}, {8, 4}

So:

  • I cleared this field in the .jucer project and regenerated the Xcode project
  • I added in my main class constructor:

    busArrangement.inputBuses.clear();
    busArrangement.outputBuses.clear();
    busArrangement.inputBuses.add(AudioProcessorBus("InputDiscrete8", AudioChannelSet::discreteChannels(8)));
    busArrangement.outputBuses.add(AudioProcessorBus("OutputAmbi", AudioChannelSet::ambisonic()));

  • I overrided setPreferredBusArrangement:

    bool setPreferredBusArrangement (bool isInputBus, int busIndex,
                                     const AudioChannelSet& preferred) override
    {
        const int numChannels = preferred.size();
        if (isInputBus)
        {
            if (numChannels < 1)
            {
                return false;
            }
        }
        else
        {
            if (numChannels != 4)
            {
                return false;
            }
        }
        return AudioProcessor::setPreferredBusArrangement (isInputBus, busIndex, preferred);
    }

  • The plugin builds
  • I start a new REAPER project and I create a new track and instantiate my plugin
  • As REAPER continuously processes the plugins, it immediately crashes:

with i = 4

Going up in the call tree:

where numChannels = 8, numIn = 2, numOut = 4

  • I see that this exact line has changed in commit e29e9ee2e3b5472f58c0320b176ff57c94165b6f

And the previous version does not crash, so this is a regression with REAPER.

  • Also, now this is what I can see in the routing matric of the plugin in REAPER (when replacing numChannels with jmax (numIn, numOut)):

i.e. channel do not hold the right names (just the bus name), plus only two channel input is available — I had 8 channels before the bus arrangement rework: here is a screenshot of a previous version:

I hope my bug report/regression report helped, and I hope you'll find & fix what caused these regression:

  • REAPER crash
  • channel names
  • number of input channels

All the best

 

EDIT ===============================================================

By reintroducing the following code that was removed in the same exact commit, I get "my" 8 channels back in REAPER:

            const int numInChans  = filter->busArrangement.getTotalNumInputChannels();
            const int numOutChans = filter->busArrangement.getTotalNumOutputChannels();

            setNumInputs (numInChans);
            setNumOutputs (numOutChans);

            floatTempBuffers.channels.calloc ((size_t) (numInChans + numOutChans));
            doubleTempBuffers.channels.calloc ((size_t) (numInChans + numOutChans));


hope it helps.


#2

Thanks for the report. I'll look into this. 


#3

By the way, there is a typo in this comment:

// You cannot add a bus in your processor wich does not support any layouts! It must at least support one.

wich -> which


#4

Thanks I'll fix this. I'm also currently working on the REAPER crash bug and the surround layout channel order problems. I have fixes for most backends except AAX. I'll push them after some more testing on Monday. Thank you for your patience!!


#5

OK this is now fixed on the latest tip. As you want ambisonic output, you should also set the default layout of your plugin to ambisonic in the constructor of your plug-in. For example, with the following code along with your setPreferredBusArrangement implementation:

MyPlugIn::MyPlugIn()
{
    busArrangement.inputBuses.clear();
    busArrangement.outputBuses.clear();
    busArrangement.inputBuses.add (AudioProcessorBus (String ("In"), AudioChannelSet::discreteChannels(8)));
    busArrangement.outputBuses.add (AudioProcessorBus (String ("Out"), AudioChannelSet::ambisonic()));
   .
   .
   .
}

Please let me know if this works for you?


#6

Hi Fabian,

Thanks for the patch, the bugs with REAPER have disappeared, I've not encountered any issue since the update.

Can I ask if you intent do work on the channel order (e.g. L R C vs L C R)?

Also, here is a small suggestion patch:

diff --git a/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp b/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp
index 4a18492..407095c 100644
--- a/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp
+++ b/modules/juce_audio_plugin_client/VST/juce_VST_Wrapper.cpp
@@ -1079,8 +1079,9 @@ public:
 
         String channelName = busInfo.name;
 
-        channelName +=
-            String (" ") + AudioChannelSet::getAbbreviatedChannelTypeName (busInfo.channels.getTypeOfChannel(index));
+        if (channelName.isNotEmpty())
+            channelName += String (" ");
+        channelName += AudioChannelSet::getAbbreviatedChannelTypeName (busInfo.channels.getTypeOfChannel(index));
 
         channelName.copyToUTF8 (properties.label, (size_t) (kVstMaxLabelLen - 1));
         channelName.copyToUTF8 (properties.shortLabel, (size_t) (kVstMaxShortLabelLen - 1));

All the best


#7

The channel order bugs should be fixed on the latest tip. Can you tell me in which DAW and with which format you are seeing inconsitencies? Note that the channel order will always be LRC in juce but will be mapped to the correct channel order depending on the DAW. So, for example in ProTools,  input audio will be mapped from LCR to LRC, then passed to your processBlock function, after which the output audio is mapped from LRC to LCR. 

Looks like a reasonable patch. I'll add this to JUCE...