@harryg +1 to basically everything you said. Let’s see if we can make this happen!
come on man, enabling github issues is just a checkbox click right away. you will find the time to setup JIRA on your own server integrated with the juce website in the future, if that will be ever needed.
Fun fact: last year we tried JIRA for tracking bugs internally, and everyone in the JUCE team hated it (including myself). It slowed us down a lot. So we got rid of it very quickly. On the other hand, JIRA worked perfectly on my last job before I joined the JUCE team. So you cannot apply the same tools that worked with one team to another one. Every project has its own requirements.
Also, as the JUCE team we operate within a larger company (ROLI) which also has their own developer teams we are closely cooperating with. So whatever new systems we introduce (bugtracker, build server etc.) needs to be aligned with the rest of the company.
Just saying, it’s not “just a checkbox click right away” @kraken
Work checking out TRAC - it comes with a Wiki and issue tracking. Raising and managing issues is super easy - and there’s an easy install version out there you can run up on a VM - took about 15 minutes.
exactly when the bloat begun.
2 Likes
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. 
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.
5 Likes
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.
6 Likes
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 !!
8 Likes
your awesomeness is awesome.
i’m crying
2 Likes
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}
{12,12}
{0, 1}, {0,2}
{1,1},{2,2},{3,3},{4,4},{5,5},{6,6},{7,7},{8,8}
{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},{3,3},{4,4},{5,5},{6,6},{7,7},{8,8}
{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! 
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 
1 Like
“get over it!” was really meant humourously (I keep underestimating the power of not hearing one’s tone of voice the forum 
): 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.