Best way to define a plugin's channel configuration

Audio Plugins
1


Hi all,


I am wondering if you can point me in the direction of the right way to configure channels for a plugin.  I have been a JUCE user for only a short time, and the recent changes have me a little confused about the best way to go.


I noticed in the Introjcer that the field for Plugin Channel Configurations shows as deprecated, which (guessing) is due to the new multi-bus code, and would like to understand how this change effects these configurations across the different platforms.


So, I did a test with xcode 7, osx 10.10, Roli Plugin Host, and Roli Plugin Demo.


Plugin Demo has a Plugin Channel Configuration of {1,1}, {2,2} and shows:
AU   - two audio ins, one midi in, two audio outs, one midi out
VST2 - one audio in, one midi in, one audio out, one midi out
VST3 - one audio in, one audio out


I removed that so that the Plugin Channel Configuration field is blank and now it shows:
AU   - two audio ins, one midi in, two audio outs, one midi out
VST2 - two audio ins, one midi in, two audio outs, one midi out
VST3 - two audio ins, two audio 


Another test I did with a plugin that has "is a synth" checked and a Plugin Channel Configuration of {1,1}, {2,2} results in:
AU   - one midi in, two audio outs
VST2 - one midi in, one audio out
VST3 - one audio out


I have a feeling that there are some other relevant settings which cause the third test to be weirder than it should ahve been.  Not surprisingly, none of these outcomes were what I had expected so I am now considering that there is something that I am missing.


Is there a specific method that should be used to make these consistent and correct across each plugin type?

Thank you very much!
 

2

Welcome to the world of plugin channel-configurations ;-)  The behavior will be different across plugin-types, also different between plugin hosts.

I think the old makro, which is now depracted, has ha different behavior, because its set the first of all configurations as standard, and not the maximum?!

Normally you define the default channel-config in the constructor, and other possibilities by overriding the setPreferredBusArrangement method.

The way its now implemented (setPreferredBusArrangement) , its a little bit confusing, because it either will check only one specific bus, and only input or output channels at one time, but without any relation to other busses.

Would be cool if there would a tutorial, how this should be  set for standard use cases ( So it will work in Cubase, Logic, ProTools, Sonar, Reaper, Ableton Live, Bitwig, Studio One, Tracktion, Wavelab, Nuendo, Mainstage, Samplitude,  ... )

Plugin which is suitable for mono/stereo/surround (which should be the default i think, so that in normal use-cases nobody has to care about channel-configurations)

Plugin which uses side-chains

etc...

 

 

 

3

I agree - a video should have been released to cover the changes and new implementation. I think a lot of us have coded our own changes to JUCE to handle multi-out and we now need to switch to the 4.x versions – so a quick video demonstrating the new paradigm would have been useful.

Rail

4

+1

ROLI, please make 3 demo boilerplate plugins (effect, synth, midi fx) that you verify are always working in the 10 common hosts, at all times of version bump releases, and then put a note on any caveats (missing midi out, etc) in the release notes.

To me (and i guess most of us single/small-team developers) the quality assuarance is much more important than any new features that you might add.

3 Likes
5

To me (and i guess most of us single/small-team developers) the quality assuarance is much more important than any new features that you might add.

 

Couldn't agree more. Thats why i always very sensitive when there are any kind of changes, even minor things. I use 50% of my time, to make my plugins compatible to all hosts.  

2 Likes
6

---- Edited: Would have become a redundant post, so I am just clearing this out.

 

7

There's a set of plugins that are exactly what you described that were added along with the bus arrangement code in 4.1 in /examples/PlugInSamples/. I'd guess that Jules/ROLI probably already have an automated test system that tests changes accross common hosts before pushing to the public facing repo.

8

I had somehow missed the examples - they make things more clear & they work in Logic, Reaper, Ableton, and Plugin Host (haven't tested ProTools yet, but will this week).

The one thing that kind of made me cross-eyed is the lack of need for a midi in for vst3.  Both vst3 and JUCE are somewhat new to me, though, so...

I am going to need to do some more testing and dig around the code for AudioProcessor a bit more, but this looks pretty good.