Plugin binary size (4.2 = bloat)

exactly when the bloat begun.


That is true, but my feeling is that if you don’t hurry up with at least a temporary bugtracker, someone sooner or later will create one using one of the readily available free service, at least to use it as a “community driven” convenient instrument to check the state of bugs in JUCE, according to its users.

1 Like

I had more or less the same idea: what about formally appointing some of us with some testing roles?

I think that the people who have more dear some of the nastiest corner cases would be perfect for this, and would be happy to volunteer so that their case is always in the spotlight.

Of course, the amount of work per single “sheriff” should be moderate: let’s say taking 10 to 15 minutes per week to follow an established sequence of steps after having pulled the latest JUCE, ideally in a completely dedicated folder so that it doesn’t disrupt development currently in progress.

If something during the planned steps doesn’t work as expected, they should then report the condition to the JUCE team for further investigation. Working on the problem wouldn’t be required by them (although it would be possibly appreciated by the JUCE team)

If this task is carried out with regularity/upon each proposed “stable” release, I think it would add to the overall stability of the library.

I personally followed kinda the same workflow for the past months (prior to 4.2 release): every monday I pulled the latest tip into my private fork, checked if something broke, and started from there.
The choice of Monday was ideal so that I could plan the week according to the outcome of the merge.

EDIT: plus, we would have a cool “GO/NON GO” calling prior to each launch, NASA-like. :rocket:

Strange, I also work great with Jira in 2 teams and I know some others that really like it.
OK, everything’s a mater of taste…

Using a bugtracker for the community is independent from your internal developers.
E.g. the Jenkins CI server has a public Jira for the OSS version, but the company behind, Cloudbees, have their internal Bugtracker as well, e.g. for the closed-source part.
They just reference via issue links when needed.

I fortgot to mention: there is a Jira cloud version that OSS projects also get for free.
So this is one click away - of course technically spoken only.

1 Like

Imagine, then, how challenging it is for us one-man shops! The point is, you wouldn’t rewrite the Visual Studio 2015 exporter in ProJucer if you couldn’t even launch VS to check that your changes worked. The same is true for plug-ins: don’t make blind changes you can’t test! No one here is suggesting you regress one-line fixes against every DAW. But if you make substantial changes to the plug-in code, it is reasonable to expect you can and will verify that each format (AAX, AU, VST, VST3) still functions properly at minimum in its “reference” DAW (Pro Tools, Logic, Cubase).

Regarding bug trackers:

Redmine is another simple, free solution for issue tracking + wiki (it’s what we use). Or Bugzilla, if you want to go old school.

Don’t let the perfect be the enemy of the good. It is more important to have something that tracks status and priority of reported issues than to have nothing while waiting for the perfect solution that has seamless integration with the repository and the main website, other ROLI dev teams, etc.


We have just pushed a fix to github that removes the Shared Code framework and uses static linkage instead. This not only makes the binary sizes small again, but actually makes them smaller than in JUCE 4.1 due to some improvements that Fabian implemented!

Also we added a build option to strip all symbols (JUCE 4.1 and before only stripped dead symbols). If you tick this new option in the Projucer, this will reduce the binary sizes even further!

Also, since the framework thing is gone, the copy protection thingies that people say were broken should work again.

Oh yes, and because the (now statically linked) shared code is still compiled only once, build times should not increase significantly with this new version.

Please update to the newest tip, hope this fixes most of people’s problems here.


Good news! However, this latest fix breaks the build on projects that have spaces in their “binary name”.

So this is a call to “get your s**t together” great !!

I second everything in this post:

1.-. Test (automate everything if possible) - Broke build… NOGO

2.- Don’t code in the dark and throw us some marketing ploy, we don’t need that shit, we are not end users, we are developers, i give a rats ass about some “neat features” (live coding, producer, homeopathicStack), what we want: the convolution engine, the fix to multibus thing, side chain, an integrated preset system, stability across hosts.(the meat is selling audio plugins for us, if we don’t we can keep up paying for juce)

3.- You are mentioning that you are having a hard time testing across all combinations, well guess what: thats how we roll for living, and you should too, cause you are the “raw material” of which our magic products come up !

4.- Give us some stability, then throw us into our next dragon-killing quest to integrate whatever fancy thing is on the latest tip, (it seems to be that way nowadays)

5.- Set up virtual machines, test environments, whatever needed for testing… and drop the “it will take us all day crap”, well guess what, us, your customers, we do it, all the time, always, cause we are responsible to our uses, and you should be too to us.

I could go on, i have been fixing adjusting so much stuff in our build servers and automated test process to build and test things, that i don’t think we can keep up with it at this pace, definitely need branching.

And yes, all this takes us more time than we want, but we have to do it, so i don’t see why you guys can’t spent a freakin week creating virtual machines where you press play and it tests something.

And we frankly give a rats ass about the rest of the company, juce worked great without it, no reason why it can’t keep like that.

Breaking all formats for Auv3 crap is stupid !!!

Cheers, can go on for hours, 1 week i been trying to make all our products build, to no avail.

Get a fucking iLok, get us a bug tracker. Is that so hard??? Hire some of us !!


your awesomeness is awesome.

i’m crying


OK. Building projects with spaces in their name is fixed now.

1 Like

You make it sound as if we wouldn’t do these tests. In fact, for every release we have a two page test protocol just for plug-ins.

Which includes all the major DAWs and all the plug-in formats. However, in addition we need to test different layout possible formats for every plug-in. We test the new multibus layouts (NoiseGate¸ MultiOutSynth) in all the DAWs and with all the plug-in formats and the legacy layout field. For the legacy layout field we test the following legacy layouts - again for all DAWs and plug-in formats.

{1, 1}, {2, 2}
{0, 1}, {0,2}
{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}
{1, 1}, {1,2}​, {2,2}
{1, 1}, {1, 2}, {2, 2}.
{1, 32}, {2, 32}, {1, 64}, {2, 64}

In addition, we need to check the consistency of all the surround formats so we test plug-ins supporting different surround channel layouts.

So we missed testing plug-ins that have a space in their name. We have added this to the test protocol and it won’t happen again. Get over it! :slight_smile:

1 Like

take a look here > Muted VST2 outputs in Cubase after ioChanged() call

any idea in how to make it all work in cubase8 and logic would be awesome

You all missed one hell of a lot more than that in the 4.1 and 4.2 releases.

When I said

It was specifically this post from your team I was referring to: [fixed] AAX plugins created with 4.2 no longer loadable in ProTools development build:

Along with the multitude of other things that broke with the 4.2 release.

“Get over it” is a really good way to alienate the numerous plug-in developers who have voiced constructive criticism about those issues.

1 Like

What was meant is that no matter how much you test, you can never catch all bugs, so that’s one we didn’t catch and this simply lies in the nature of software development.

Yes, and thanks to everybody for this constructive criticism! All those topics (cross-platform testing, build automation, bug tracking, announcing breaking changes in advance, stable/unstable branches, our release process…) will be discussed internally in the JUCE team, our primary goal here is to improve on all those fronts. We deeply care about our users and always want our releases to provide a good experience for all of you! Whenever we fall short of this expectation, we are just as disappointed as you are and do everything in our power to fix it.

Just to give you some background on that specific incident:

What happened is that, for an act of God beyond our control, we lost our only iLok that had a ProTools Dev licence on it. ROLI doesn’t do AAX, so no-one else here had one. We went through the official process with Avid to get a new iLok and recover the licence. That’s a very slow and arduous p.i.t.a., made even slower by the fact that the owner of the licence was Fabian who was away in the US at the time. Then, due to another act of God the package with the new iLok did not get delivered and was stuck somewhere else for more than a week. So the fact we couldn’t test AAX before release was a highly unlikely combination of failures. We then reluctantly decided (looking at our code) that it was very unlikely AAX would break and it’s not worth it to put off the whole release by one more week just to test AAX. As it turned out, that was our mistake, as the unlikely fail happened again. Fair enough—lesson learned. All potentially affected code needs to be tested before release. We don’t really have to argue here :wink:

1 Like

“get over it!” was really meant humourously (I keep underestimating the power of not hearing one’s tone of voice the forum :slight_smile:): of course we know we broke a lot of stuff and we are not very happy with the way the release went. All the criticism is well justified. I can tell you we are taking the feedback very seriously.

IMHO our biggest mistake was tagging this as a release version. We should have never done that and given people the time to test the features.

However, I think we will always be breaking some stuff on the plugin side (in the future on the develop branch). This is unavoidable. I’ve read so often that simply testing in all popular DAWs would somehow be a miracle fix and just wanted to point out with my post that we do this already. Yet we can never find all the use cases you guys are using. Take, for example, the shared code stuff. It worked well with all our public and private plugins. We never thought of copy protection solutions. And it’s good we got some feedback and we changed it within days.

I think this will be a bit the norm (maybe not as bad as 4.1/4.2) especially as future plugin formats get more complicated (sandboxing etc.).

Like I said: a develop branch would have been useful.

1 Like

I isn’t just plugins that are affected - its JUCE apps too. I have both a plugin and an app ( a special kind of plugin-host ) in development and have come a cropper because of the 4.2 release.

If I may put my two cents… I’m reading about last problems and being Juce user for almost 10 years I noticed that such huge complications happen most often in plugins related stuff. Issues with base classes (usage independent) even if the classes are completely new or modified a lot are mostly minor and fixed very quickly and then such code stays stable forever.

When you reorganize plugins stuff there are always some troubles - no matter how much you modify the code. And to be honest it has to be like that (IMO) - plugins code is used in such different situations that I don’t believe that ‘stable’ state even exists. Even if you don’t make any changes then host apps/formats/OSes can change and cause the issues which need to be addressed.

It’s not about how to avoid the problems but how to live with them keeping peace of mind :slight_smile:

Here I also vote my two hands for separating the branches for different purposes because it’s mostly about the JUCE repository management - the old hidden problems mix with the new unexpected problems from the outside world and mix with the fresh problems coming from new features not tested enough - and that’s the PITA. Using something similar to GitFlow management would fit perfectly here.

Having develop branch (and feature branches if you want) you could commit what you want - new turbo-ultra-inspiring features showing us where you want to go and giving us a chance to test it and giving you our feedback. All the revolutions go here and every bug is welcome.

One release branch if you decided that it’s good time for new Juce release. You close some state to test it more before it becomes new version. Only bugfixes are made to release branch and for example after 4 weeks you could simply release new version knowing that it’s as stable as possible.

Then we could always rely on master branch and use it for our important releases. And if anything from the outside world (hosts/OSes/compilers etc) cause the problems you could simply make a bugfix to the master branch (merging it also to develop branch or wherever you want).

I don’t agree that you at Roli should make all_the_tests for plugins stuff: all the major DAWs, OSes etc before committing anything. It’s waste of your time. Please focus on Juce development and make the basic tests only. If we had dedicated branches you could make deeper tests only on new releases and we could help you then testing it also on our sides. It would be great time saver for you and us.



Thanks @bld , I second everything in your post. Good to see that some people understand the place we are coming from! :slight_smile:

In fact, we heard you and did introduce a new setup with two master and develop branches yesterday (see here). Hopefully this allows everyone here to work with the newest tip and test it in advance, while also having a stable branch available (master) that is only updated for critical bugfixes and actual releases of well-tested code.

Please keep in mind that JUCE used to be a one-man show with extremely minimalistic project management for a very long time (and that used to work very well!). So if we are to transition to more defined processes around releases, potentially a third branch for “release candidates” etc., and all those other things people are suggesting here, it has to be gradually and can’t happen overnight. Our first step are the two braches instead of one. We may do more stuff along those lines soon. Watch this space :slight_smile:

Please stop repeating this straw man argument. No one has asked for ROLI to test every configuration, every time any change is made.

The request was: if ROLI makes MAJOR changes to the plug-in wrappers or the way they are built, those changes should be put through basic regression tests on the reference platform for each format: Pro Tools, Cubase, Logic.

We get that JUCE is a small team… but the fact is many of us who depend on JUCE and are calling for increased project management are one-man shops who already practice what we preach: strict release processes, separate stable/dev git branches, bug trackers, regression testing against reference platforms, semantic versioning, etc. We’re not advocating for anything we don’t do ourselves.

That said, I’m glad to see progress being made in this area. Change always feels difficult at first, but these process improvements really will make things better and easier for everyone - including ROLI - in the long run.


Couldn’t agree more!