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.
Both VST3 and AU specification inform the plug-in of bus format changes in exactly the same fashion as we do in JUCE, i.e. that the format of each bus is set individually - and the plug-in can either reject or accept the change. This is an established way to implement such a mechanism and only VST2 does not follow this method. You will have to be a bit more specific why you doubt that this mechanism will work.
That's good news, thanks for all the effort. The other good news is the plan that Jules announced to add a bug tracker to the project, so there will be no need for the known bugs site...
Still I want to add my vote for a stable branch. Developing a new plugin, I would always use the latest tip, to squeeze the fresh drops and aromes out of the juce. And at the moment I am lucky to only have these kind of projects. But if I imagine to maintain a bunch of plugins, I really would hope for a stable branch, so I don't have to get the child-issues of a new feature stopping me from fixing a bug in an old code. And yes, I can use the old status of the juce, but eventually I need a newer version for what ever reason...
It's not a shame to have some bugs especially with new developments, which are important and add each time value to the product. But it should be the common goal of Roli and the users, to minimize the impact of changes on the users.
So it should be obvious to separate into a stable branch, well tested in-house and on the street by the users, and the currently beeing tested experimental state, also in testing by both parties.
+1 for stable/experimental branch separation
N.B. this actually doesn't belong here, because this need has nothing to do with the multibus, it is essential for ALL new developments
In addition, it could be taken in consideration the possibility to use topic/feature branches like "topic/multibus", so that users needing that specific feature can simply merge and use that.
All the testing and bugfixing would then take place in that branch until it proves to be "mature" enough to be merged into the main branch.
I think this would also result in a cleaner git history, because all the commits that fix bugs in an experimental feature will be collected in their own branch without cluttering the main line.
Thanks for your feedback on this. Having a feature branch definitely sounds like a good idea. We already do this internally at ROLI anyway. As JULES already said, we will soon be launching a public bug tracker which I think will help as well.
