4.1. setPreferredBusArrangement() mono-stereo or same Ins/Outs

[chkn]

Thanks, I'm still not happy with this design, for complex channel layouts its more like a mathematical puzzle, not intuitive. What happens if the plugin also should support stereo to surround configuration: {1,1} ; {1,2} ; {2, 2} ; {2,6} ?

[timur]

I wonder if we could write some clever template metafunction so that the compiler can write that setPreferredBusArrangement() function for us?

Something along the lines of

using SupportedBusArrangements = BusConfigurationList <BusConfiguration::MonoToMono,
                                                       BusConfiguration::StereoToStereo,
                                                       BusConfiguration::Custom<2, 6>>; 

And then the user would just define that type somewhere and JUCE/the compiler would do the rest.

[siedschl]

On a related note: I know not many people are using RTAS anymore, but have you forgotten to adapt the RTAS wrapper to the new scheme? See line 888ff in juce_RTAS_Wrapper.cpp:

 

void CreateEffectTypes() 
{ 
   const short channelConfigs[][2] = { JucePlugin_PreferredChannelConfigurations }; 
   const int numConfigs = numElementsInArray (channelConfigs); // You need to actually add some configurations to the JucePlugin_PreferredChannelConfigurations value in your JucePluginCharacteristics.h file.. 
   jassert (numConfigs > 0); 

which gives me an error when not providing a JucePlugin_PreferredChannelConfiguration, obviously.

[chkn]

This would be great!

[fr810]

Currently we don't support multibus on RTAS at the moment. You need to use the legacy channel configuration field in the introjucer for RTAS.

[timur]

RTAS is pretty much dead and we will deprecate it, AAX is the way. There are a very few folks on ancient systems who still run RTAS plug-ins, and we will try our best to not break compilation of existing RTAS plug-ins with JUCE for legacy reasons, but no new development will go into RTAS and we strongly discourage using it for new projects.

So I'd say it's safe to assume that multibus for RTAS won't happen.

[lapsang]

Please, please...do something like that! If someone wants super complex configurations then they can deal with setPreferredBusArrangement on their own.

[KoenTanghe]

I have a plugin which uses the old channel configuration {1, 1}, {1, 2}, {2, 2}.

When simply I rebuilt the plugin with the tip of Juce of today, and then launched the plugin in Plogue Bidule, it's now showing 4 different combinations (where there only used to be 3):

1 ins, 1 outs
1 ins, 2 outs
1 ins, 6 outs          <--- new (?)
2 ins, 2 outs

I understand I'll need to switch to the new way of defining the combinations, but just wanted to signal that backwards compatibility with the old way doesn't seem to be entirely correct right now (only tested in Plogue Bidule a.t.m.).

 

[fr810]

Upgrading to JUCE 4.1 and using the legacy channel configuration should work out of the box. If it doesn't then it's a JUCE bug. Before I investigate, can you confirm that you have re-built the Introjucer after upgrading to JUCE 4.1. You also need to re-save your JUCE project with the new version of the Introjucer.

[fr810]

 I've now published a sticky on this topic.

[KoenTanghe]

Hi Fabian,

yes, that is what I had understood, and why I posted my findings. I did rebuild the introjucer and re-saved my project.

In order to help you look into this, I also tried with the audio plugin demo, and could reproduce this: same results as with my plugin.
Reproduction steps I used (this is on Windows7 64-bit latest updates):

 

1. start "Knitevision" from Photek's "Form and function" album: https://www.youtube.com/watch?v=qIyjaSSUvfU&t=40m45s
2. pull latest Juce changes from master tip
3. build vs2010 release version of introjucer
4. open JuceDemoPlugin.jucer from JUCE\examples\audio plugin demo in just built introjucer and:
   - change existing Plugin Channel Configurations to {1, 1}, {1,2}, {2, 2}
   - uncheck Build VST3 (no sidechaining or multi-buses needed, only want to build VST2, not VST3)
   - change VST Folder to C:\SDKs\VST3 (unzipped vstsdk365_12_11_2015_build_67 file)
   - do Save all + Save project
   - close introjucer
5. open vs2010 solution of audio plugin demo + build Debug version
   Shows several warnings:
   Warning    1    warning C4996: 'juce::AudioProcessor::getInputChannelName': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   Warning    2    warning C4996: 'juce::AudioProcessor::getOutputChannelName': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   Warning    3    warning C4996: 'juce::AudioProcessor::isInputChannelStereoPair': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   Warning    4    warning C4996: 'juce::AudioProcessor::isOutputChannelStereoPair': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   Warning    5    warning C4996: 'juce::AudioProcessor::getInputChannelName': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   Warning    6    warning C4996: 'juce::AudioProcessor::getOutputChannelName': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   Warning    7    warning C4996: 'juce::AudioProcessor::isInputChannelStereoPair': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   Warning    8    warning C4996: 'juce::AudioProcessor::isOutputChannelStereoPair': was declared deprecated    e:\koen\code\various\c++\juce\examples\audio plugin demo\source\pluginprocessor.h    117
   but otherwise clean build.
6. make sure there are no older JuceDemoPlugin.dll files strolling around in any VST directories
7. copy the just built JuceDemoPlugin.dll to VST2 plugins folder known by Plogue Bidule (in my case: C:\Program Files (x86)\Common Files\Steinberg\VST2)
8. launch Plogue Bidule (32-bit version)
9. instantiate audio plugin demo
   --> shows as possible configurations:
       1 ins 1 outs
       1 ins 2 outs
       1 ins 6 outs    <--------
       2 ins 2 outs
       default ins default outs

This was tested in Plogue Bidule 0.9748 (x86-32 standalone).
I'll try two more things:
- double-check how the original configuration of the audio plugin demo shows up (different plugin, same host)
- see how the Juce audio plugin host application handles this (same plugin, different host)

By the way: I really appreciate the work you guys have been doing these last months, and understand that more people interested in Juce also means more support work. Keep going!

[railjonrogut]

Thanks Fabian,

My plugin has:

and I have it working in JUCE 4.0 with my modified AAX and RTAS wrappers and with VST2 and VST3… The only format which I don’t have multi-out support for is AU.

I don’t use any SideChaining and the Aux Outs are not Surround, etc).

The question is: If I upgrade to JUCE 4.1 (and lose my mods) and keep the above config will all the formats work or should I switch to the new MultiBus system?

Thanks,

Rail

[KoenTanghe]

OK, I also tried these things now:

1. I did all the same steps as in my previous post (last Juce from master), except changing the channel configurations (so that remained on {1, 1}, {2, 2}). The result was that also in that case the channel configurations showed up as follows in Plogue Bidule:

    1 ins 1 outs
    1 ins 2 outs
    1 ins 6 outs    <--------
    2 ins 2 outs
    default ins default outs

2. I performed a git reset hard on the my Juce code tree, back to tag 3.2.0 (SHA-1: 861d3d971016144cbfd17f97e7d735a354caa647), rebuilt the introjucer, re-saved the audio plugin demo project, and then performed the same settings as in my first post above: 3 configurations ({1, 1}, {1,2}, {2, 2}) instead of 2, only VST2 version. [I know, a git switch to that tag should actually be sufficient, but well, I did a reset hard anyway]

After building the audio plugin demo with Juce 3.2.0, and re-sanning the plugins in Plogue Bidule, the possible channel configurations now show up in that host as:

    1 ins 1 outs
    1 ins 2 outs
    2 ins 2 outs
    default ins default outs

which is what I have for the previous build of my own plugin as well, and what is expected.

 

A few thoughts from these experiments:

- something broke between 3.2.0 and 4.1, and it's reproducible with the audio plugin demo

- maybe it has something to do with the fact I disable VST3 and only use VST2? (I didn't continue testing that as well, as I was kind of tired by then, making sure I did everything without mixing up versions/configurations...)

Hope this helped give you a starting point to find the problem.

[fr810]

I believe it should work but haven't tested 32 output channels myself. Please let me know if it works for you.

[fr810]

Instead of doing some template magic like that, we have decided to simply use the "PlugIn Channel Configuration" field in the Introjucer. I've removed the deprecated warning on that field.

[fr810]

Thank you for this detailed bug report. I'll have a look at this.

[fr810]

OK. This is now fixed along with a few other channel layout issues in VST2. Please update to the latest tip.

[railjonrogut]

It looks like it’s going to be far from simple… I have a very involved AudioProcessorGraph which I initialize in my main AudioProcessor class (this is a Synth BTW)…

#ifndef  JucePlugin_MaxNumInputChannels
 #define JucePlugin_MaxNumInputChannels    2
#endif
#ifndef  JucePlugin_MaxNumOutputChannels
 #define JucePlugin_MaxNumOutputChannels   32
#endif

m_pMainGraph->setPlayConfigDetails (JucePlugin_MaxNumInputChannels, JucePlugin_MaxNumOutputChannels, m_dMainSampleRate, m_iMainBufferSize);

adding:

    // Add additional aux output buses:

    for (int busNr = 1; busNr < 16; ++busNr)
        busArrangement.outputBuses.add (AudioProcessorBus (String ("Aux ") += String (busNr + 1), AudioChannelSet::stereo()));

and changing my code to:

m_pMainGraph->setPlayConfigDetails (getTotalNumInputChannels(), getTotalNumOutputChannels(), m_dMainSampleRate, m_iMainBufferSize);

I still hit an assert in AudioProcessor::setPlayConfigDetails()

I’ll have to dig into this and figure out what’s going on…

Rail

[fr810]

Have a look at the new documentation of setPlayConfigDetails:

This is called by the processor to specify its details before being played.

Use this version of the function if you are not interested in any sidechain or aux buses and do not care about the layout of channels. Otherwise use setRateAndBufferSizeDetails.

For plug-ins with sidechains and aux buses you should now first call setPreferredBusArrangement, followed by a new function introuced to JUCE 4.1 called setRateAndBufferSizeDetails.

Normal plug-ins should rarely need to call those functions (in the same way as you would rarely call setPlayConfigDetails).

Also, note that JUCE 4.1 does not yet support hosting multi-bus plug-ins.

[railjonrogut]

For plug-ins with sidechains and aux buses you should now first call setPreferredBusArrangement, followed by a new function introuced to JUCE 4.1 called setRateAndBufferSizeDetails.

Should that be “For plug-ins with side chains and/or aux buses” or is it accurate?

Also… I thought the host called setPreferredBusArrangement() – so we should call that in our constructor and then setRateAndBufferSizeDetails() ?

Perhaps that can be added to “The ultimate JUCE 4.1 MultiBus Guide”.

Also, note that JUCE 4.1 does not yet support hosting multi-bus plug-ins.

Aah…. any idea when we can expect the Host to support multi-bus ?

Thanks,

Rail