This is becoming frustrating. I'm on the latest tip, re-built the IntroJucer, VST (2.x) are still loading as mono {1, 1} when loaded on a stereo track, using {1, 1}, {2, 2} configuration in the IntroJucer (I remember this same problem was fixed a while ago).
AU version is fine.
Using setPreferredBusArrangement to get {1, 1}, {2, 2} fixes the problem, but then, again, why having the channel configuration in the IntroJucer? Should we just use setPreferredBusArrangement and forget about the channel configuration in the IntroJucer?
In Reaper, the reported input channels for the stereo configuration are called 'Input C' and 'VST In 2' and the output channels are called 'Output C' and 'VST Out 2'. Only the '... C' is set via getPinProperties() with index == 0. This might help in figuring out the cause of this issue.
Could you add information available in 'The ultimate JUCE 4.1 MultiBus Guide' like e.g.
The main input/output of an effect plug-in is referred to as the main bus and denoted with an index of zero in JUCE
to the comments in the source code as well? Would be quite helpful when debugging.
Thanks, but now there's another problem. If I add {1, 2} it's still messed up. For example, In Live, which loads only stereo tracks, it will load {1, 2} making a stereo clip, mono.
As said in other threads, the most common configurations for effects are {1, 1}, {2, 2} and {1, 1}, {1, 2}, {2, 2}. These should work without efforts, without complex setPreferredBusArrangement configurations.
If the legacy configuration is so complex to maintain, would be nice to have some macro or methods to call in the plugin constructor to load the common configurations. Otherwise I guess I'll just stick with setPreferredBusArrangement and make my own macros/methods/whatever.
I think the problem is due to the break in the code you added. Should be probably like that:
// prefer stereo if available
for (int i = 0; i < numChannelConfigs; ++i)
{
if (channelConfigs[i][0] == 2 || channelConfigs[i][1] == 2)
{
defaultLayoutIdx = i;
// don't break, {2, 2} should be prefered over {1, 2}
}
}
But I'm not sure if this might causes other problems. I don't really trust the "legacy" code anymore, I spent weeks checking tons of hosts and configurations on both MAC and Win while replying to tens of customers reports. I have several updates to release, I can't do that all over again.
I'll move to setPreferredBusArrangement and pray it won't break anything else or won't be changed in a month or so.
OK the problem should be fixed now. I know that these changes may be frustrating but please be assured that the legacy field in the Introjucer should not break any plug-ins - if it does, then it's a bug in JUCE - of which, admittedly, there have been many recently. However, we are doing our best to fix them as soon as possible.
It's incredibly difficult to test all the variants of hosts, plug-in formats and channel layouts. We are doing our best to cover the most common cases and I have added DAW/plug-in/channel layout combination to our internal test list which come up often on the forums (for example, I just added {1,2} as a legacy layout to test with Live).
However, I'd also like to point out that there was a test period for the multi-bus feature which was plublised on the forums in a sticky note. I only received very little feedback from users during this phase (thanks to the hardcore JUCEers who gave valuable feedback). I'd urge users to take such test periods more seriously to avoid problems in the future.
I'd urge users to take such test periods more seriously to avoid problems in the future.
In this case, instead of pointers fingers towards users, Roli is the one who can take preventative steps up front.
Some extra effort and diligence on your part with regularly writing unit tests into the library, along with getting hooked up to continuous integration, and even running through standard testing practices can really curb the amount of issues that drop suddenly or slowly creep up. This is also what dedicated QA testers are for, and even why automated testing apparatuses exist (http://appium.io/ ?) - to catch any rubbish before it reaches the public's hands.
Hell, the amount of variables and potential for hiccups you can test just internally with the AudioProcessor class is immense - yet, where are its unit tests?
Hi jrlanglois, I disagree somewhat. You are right that the JUCE team needs to add more automatic tests and manual test procedures and we are currently working on this by setting up the necessary systems. However, some things do not lend itself very well to automatic unit testing and, unfortunately, most of the plug-in wrapper stuff cannot be unit tested. In fact, looking at the history of the bugs in the multibus implementation, it is unlikely that any of the bugs would have been spotted by unit tests. Therefore, even with your suggestions we would probably be in a similar situation today.
Again, the number of combinations of Plug-In formats/DAWs/channel layouts is overwhelmingly large and I think it is justified to ask users for their feedback in this case.
I somewhat agree with you, but not entirely. Even if that's correct to ask user's feedback, since the combinations are really huge, I sense something like a huge pressure to get the sidechain and multibus working that the basics (easy and correct implementition of mono, stereo and mono->stereo) has been lost during the path.
I'd also like to point out that there was a test period for the multi-bus feature which was plublised on the forums in a sticky note.
Ha, this is the problem, i don't have the time/resources to check all combinations (which were already working), possible problems, because of a features i don't need - well otherwise someone pays me for that.
Maybe you now understand why i was (am) in panic-mode when the new channel-config methods were introduced.
I needs to be tested in all major and minor hosts, with all kind of possible channel-configuration, BEFORE its being released. That is huge work, but there is no other way around.
I hate to say that, but i'm still think the new setPreferredBusArrengement method is broken by design, because there is now way to check the corresponding (in/out) channels in a proper way.
I'm still on JUCE 4.0 and i fear how many time i will lose when i switch to 4.1. (to reproduce same functionalty)
The spate of issues around the multibus implementation is a perfect example of why I've repeatedly requested JUCE separate stable (release) and development (tip) branches, or otherwise consistently and accurately identify stable points in the repo.
We get that JUCE devs don't intentionally check in unstable or broken code. No one does. But when you have a large base of developers with products at various stages relying on your code, it is not reasonable to just say "always use the tip". Sometimes the problems introduced take more than a quick fix to resolve, which means the tip is broken for weeks at a time (or more).
There are many mechanisms available for addressing this issue (gitflow Develop/Master, odd/even versioning, consistent tagging of latest "stable").
Please take another look at implementing any of these processes so that your customers have the ability to identify known "stable" points in the repo.
JUCE separate stable (release) and development (tip) branches, or otherwise consistently and accurately identify stable points in the repo.
Yeah, that'd be wonderful: having many products based on JUCE to mantain, I've found myself way too many times searching for the next "best" commit in the JUCE history for periodic continuous integration.
As the multibus experience shows (and other "fixed previous broken commit" messages), blindly updating to the tip is hardly the best move for that.
Again, the number of combinations of Plug-In formats/DAWs/channel layouts is overwhelmingly large and I think it is justified to ask users for their feedback in this case.
I'd like to challenge that by saying there's a bit of confusion between feedback and process. The former is fine to some extent, but the lack of the latter is diminishing user-confidence in the code.
However, some things do not lend itself very well to automatic unit testing and, unfortunately, most of the plug-in wrapper stuff cannot be unit tested. In fact, looking at the history of the bugs in the multibus implementation, it is unlikely that any of the bugs would have been spotted by unit tests. Therefore, even with your suggestions we would probably be in a similar situation today.
This would be the main reason I suggested QA tester in my previous post: to dedicate someone (or many!) into testing the crap out of the code, to objectively and deeply break it, but also to take away developer burden.
It looks like, that certain configuration possibilities are simply not possible without the legacy functionality because setPreferedBusArrangement, ask only for the input or output configuration an a certain bus separately not for the whole image at once.
This is simply not correct. All configuration possibilities are possible with setPreferredBusArrangement. In fact, the legacy Introjucer field is implemented with setPreferredBusArrangement since JUCE 4.1. So everything that was possible with the legacy field is definitely possible with setPreferredBusArrangement. Furthermore, the setPreferredBusArrangement now adds layouts which would not have been feasible with the old legacy field.
Please re-read rule #4 in the multibus sticky:
If there is a way for your plug-in to accept a requested channel layout, then you must accept this request even if it involves changing the channel layout of other buses. This must always be done indirectly by calling the base class version of setPreferredBusArrangment. (see rule #1)
JUCE is perfectly able get a full view of your plug-in as it uses an algorithm to work out all possible combinations of your plugin which are compatible with a certain plug-in format.
the legacy Introjucer field is implemented with setPreferredBusArrangement
yes, i know, but if you look it how its implement, it calls back busArrangement - variable, which is the current-layout by default, and not the possible new layout.
And when i understand the VST-Wrapper right, it sets the setSpeakerArrangement for the input first, than calls
setPreferredBusArrangement, in this moment the plugin cannot know what the expected output configuration is, it has to either accept or not.
Even if its working (which I doubt), the legacy implantation, is based on a hidden logic how the wrapper may use this class, but nothing you can really rely on.
And even if there is a logic behind all this stuff, its just to complicated, really!, the amount of documentation, bug-fixing etc... which is affordable speaks for itself.
I've finally been able to fix the Logic Sidechain feedback issue. So we are not aware of anymore bugs in the multibus implementation (& the legacy channel configuration field). Please report any other bugs you find.
