Plugin Channel Configurations JUCE 4.1. workaround not working as expected in Cubase

Audio Plugins
1

I have a lot of old Plugins, which using the old Plugin Channel Configurations-Definition.

For example

{1, 1}, {1, 2},{1, 3}, {1, 4},{1, 5}, {1, 6},{1, 7}, {1, 8},{2, 1}, {2, 2},{2, 3}, {2, 4},{2, 5}, {2, 6},{2, 7}, {2, 8},{3, 1}, {3, 2},{3, 3}, {3, 4},{3, 5}, {3, 6},{3, 7}, {3, 8},{4, 1}, {4, 2},{4, 3}, {4, 4},{4, 5}, {4, 6},{4, 7}, {4, 8},{5, 1}, {5, 2},{5, 3}, {5, 4},{5, 5}, {5, 6},{5, 7}, {5, 8},{6, 1}, {6, 2},{6, 3}, {6, 4},{6, 5}, {6, 6},{6, 7}, {6, 8},{7, 1}, {7, 2},{7, 3}, {7, 4},{7, 5}, {7, 6},{7, 7}, {7, 8},{8, 1}, {8, 2},{8, 3}, {8, 4},{8, 5}, {8, 6},{8, 7}, {8, 8}

This will be opening in Cubase as mono-plugin, before JUCE 4.1. it was opening as stereo plugin on a stereo track.

Either you should remove the workaround, or replace it with something which is working.

 

 

2

There is a similar problem with the GainPlugin example. Theorically, it accepts all layouts with the same number of channels in input and outpout.

If its VST version is inserted in a quad track, it has only 2 channels. The only way to get 4 channels is to accept only 4 channels layout in setPreferredBusArrangement. It seems that the first compatible layout is choosen, not the best.

There is no problem with VST3 version, it has 4 in and 4 out.

 

Cubase 8, Juce 4.1, OSX 10.11.2

 

 

3

A similar thing happens for me with a simple {1, 1}, {1,2}​, {2,2} plugin. Now it is created as {1,1} when inserted on a stereo track. Before the new bus logic, it was instantiated as {2,2} on a stereo track.

Using {2,2}, {1, 1}, {1,2} appears to fix the issue, but is this the way this should be done?

 

4

It seems like every year, posts like this come up. How is this not automated in some intuitive way by the Introjucer by now?

Surely you could have a list of a handful tickable speaker configurations (e.g.:  mono, stereo, quad, 5.1, 7.1), and room for custom ones (e.g.: I want my plugin to support 22.2, so I type in 22.2 and Introjucer magically knows what that means), and error-prone configurations like

{1, 1}, {1, 2},{1, 3}, {1, 4},{1, 5}, {1, 6},{1, 7}, {1, 8},{2, 1}, {2, 2},{2, 3}, {2, 4},{2, 5}, {2, 6},{2, 7}, {2, 8},{3, 1}, {3, 2},{3, 3}, {3, 4},{3, 5}, {3, 6},{3, 7}, {3, 8},{4, 1}, {4, 2},{4, 3}, {4, 4},{4, 5}, {4, 6},{4, 7}, {4, 8},{5, 1}, {5, 2},{5, 3}, {5, 4},{5, 5}, {5, 6},{5, 7}, {5, 8},{6, 1}, {6, 2},{6, 3}, {6, 4},{6, 5}, {6, 6},{6, 7}, {6, 8},{7, 1}, {7, 2},{7, 3}, {7, 4},{7, 5}, {7, 6},{7, 7}, {7, 8},{8, 1}, {8, 2},{8, 3}, {8, 4},{8, 5}, {8, 6},{8, 7}, {8, 8}

can be generated?

5

We recently replaced the entire bus configuration system - the kind of code in this post is just a legacy thing now.

6

Yes, this thread is about the legacy-functionality which i think is broken.

But also the new system, i don't understand how the channel input/output channel configurations can be checked in conjunction to each other. If i look into the wrappers code (for example vst) it sets the input configuration first, but how should the plugin know what the suggested output configuration is (at the same time, its not set yet), to accept or  disagree to the current complete channel layout.

As described in the comments, the plugin may also change the channel layout of other buses in the setPreferredBusArrangement callback, which makes it even more confusing (the combined inter-bus setter/getter functionality) 

Shouldn't it be more like this?

// Plugin returns all possible AudioBusArrangements, then the wrapper bargains with the host, which channel-configuration should be used. 

Array<AudioBusArrangement> getPossibleAudioBusArrangements ()

OR alternatively:

// Plugin checks  if the AudioBusArrangement suggested by the host/wrapper is allowed

bool isPossibleAudioBusArrangements (AudioBusArrangement)

AND finally 

// Plugin return its default Input/Output-Configuration

AudioBusArrangement getDefaultAudioBusArrangements ()

 

7

True, but being deprecated doesn't mean old code should break. Now it looks like there is compatiblity with old code where in reality problems are going to happen with VST if pre-JUCE 4.1 plugins are recompiled.

The Juce audio plugin example still uses this mechanism and is broken as well.

8

I wasn't saying old code should break, I was just replying to jrlanglois's post about it not being a good design.

9

Just got the same problem. I have {1, 1}, {2, 2} in the IntroJucer, the AU version (in Logic X) works fine but the VST (in Live 9) loads as mono {1, 1} on a stereo track. 

Leaving the Channel Configuration field empty fixes the problem, BUT apparently broke something else in the AAX version (AAE error -7106).
I can't test right now, but the only thing I changed was that.

I didn't test it on Windows.

10

The legacy layout macro is now fixed on the latest tip. See also this post.

11

Why not sticky that sort of thing, or announce the change with appropriate migration steps?

It's great that the feature was mentioned here (http://www.juce.com/forum/topic/juce-41-released), but it doesn't really elaborate on how to transition from the initial crude system to the new one, and it's not obvious outside of the forum that the feature changed.

I must suggest that you guys make it obvious for everyone when features are changed drastically, with easy reference points, and clear and tested steps to migrate.