Since 4.2 audio plugins are much bigger – the demo plugin in Release, universal binary has grown from 3.8MB to 15.4MB. About the same weight has been added to my plugins. This seems like a waste for no apparent user gain. I assume it’s because the ‘Shared Code’ library is compiled separately, and thus the compiler/linker can’t know what can be stripped out. Do you agree with this assessment?
If so, a workaround would be to remove all unused modules in Projucer. Though that only gets us halfway – unused parts of each module will still be present, and it’s a hassle to manually keep track of what’s used and not.
The “real” solution for us size-conscious would be to re-introduce the monolithic builds (i.e. no shared code). For me, the downside would be minimal – sure, doubled compile time when building AU + VST, but during development it’s fine to just build one of them.
I have the feeling that all plugin-specific “improvements” in 4.1 and 4.2, will force people to use their own 4.0-repository with back-ported bug-fixes.
I always tried to be on the latest tip, but its nearly impossible now, I don’t have the nerve to be a pioneer anymore. This is not good for the framework at all, but it means, that issues in the current version not being fixed.
Please keep in mind, a plugin developer has to care about
32/64 bit, windows / mac, VST/VST3/AU/AAX. Its not enough if only 90% is working.
There a thousand of different combinations, even the slightest change, can have a big impact on end-user experience. Any change needs to be tested intensively on all major hosts, and and all platforms combinations, with all channel-configurations, before they go into the main repository.
I am under the impression that, the bigger the update to JUCE is, the smaller is the number of developers that are willing to take the risk to update, knowing how bug-prone the fresh code could be (especially those experienced enough to have been bitten by similar issues in the past)
A huge change like the one brought in by 4.2 effectively had the potential for grinding the update rate almost to a halt, unless for those few brave of us that can’t make without the bugfixes added to the tip (and only there ).
The net result is that the big chunk of new code will not be tested as quickly as if it had been introduced in small amounts, which leads to the bugs surviving for far longer time, which also reinforces the feedback that “better wait before updating”…
i think it’s a problem on the way things are handled now. coding in the shades without help, feedback and testing from the real users, then releasing to the public the new big marketing thing without putting the required care and craft is a bad move. and it’s a pity because juce in the last ten years was never run like this, the opposite in fact… constantly evolving and improving with no huge jumps in the void, responsiveness was the key, we all where present to fix the new class, the new code, the new bug in that particular host. it’s starting to become a bit too corporate now. two weeks after the wonderful release… have you seen some commits regarding the awesome multibus thingie? nops… probably we will look next week. i don’t feel i want to waste more of my time debugging it. it doesn’t deserve it. in the meanwhile you will be happily maintaining a separate branch backporting bugfixes. hurray!
I’m a little floored that JUCE/ROLI appears to be making significant changes to plug-in support without the ability to verify proper functionality of some formats (AAX), and without consulting the numerous developers on this forum who have been doing professional plug-in development for decades.
A number of decisions in the 4.2 release (and the continued breakage from the 4.1 multichannel implementation) belie a naivite with the subtleties of the plug-in formats and the practicalities of commercial plug-in development.
There are many constraints to juggle in actually publishing a professional plug-in: individual plug-in SDKs, OS SDKs, copy protection SDKs, and JUCE… not to mention a userbase that skews heavily away from the bleeding edge. Multiply this by many projects at different stages of development and developed at different times, and it can be an enormous undertaking to keep it all working.
A common underlying framework like JUCE is supposed to make this easier. Indeed, that’s why I have embraced JUCE. I, like many other professional plug-in developers on these forums, have developed my own workarounds for those areas of JUCE where plug-in support is incomplete or inadequate.
It is very, very troubling, then, to have substantial changes made to the architecture and operation of that framework that break those workarounds and break established workflows and appear to have been done without proper testing and seemingly with little awareness for the realities of commercial plug-in development. ProJucer live compiling is really neat – and completely useless to me. AUv3 support is cool, I guess, but when it means reorganizing the way plug-ins are built, that breaks a bunch of other parts of my build process. It’s frustrating to see JUCE development effort spent on these kinds of things when, for example, the multichannel implementation has remained broken for months.
Please consider the following suggestions for improving JUCE’s approach to plug-ins:
Announce proposed major changes prior to implementation. Leverage the considerable experience of the plug-in devs among the JUCE community. We have many decades of experience with the ins and outs of different format SDKs and host idiosyncracies, as well as the requirements of certain copy protection systems that are an unavoidable part of commercial plug-in development. Let us point out the landmines before you drive us all out into the field.
TEST ALL THE FORMATS. It appears from some posts that JUCE devs are making changes without the ability to perform even a basic sanity check for some formats (ie. if you can’t launch Pro Tools, you shouldn’t be making changes that affect AAX).
Split stable and dev branches. The last truly “stable” commit with regards to plug-ins is somewhere around December of last year - pre 4.1. The notion that everyone should just use the tip and that reported issues will only be considered if you’re on the tip wasn’t ever a great way to do things and REALLY doesn’t work when the tip is broken for months at a time, or when there are substantial changes to the build process.
Don’t introduce unnecessary arbitrary constraints (forced use of Intro/ProJucer, specific OS SDKs, specific compiler settings). Many of us have to integrate our JUCE projects with other elements. Getting all those parts to play nice can be a nightmare of conflicting requirements.
Set up proper bug and feature request tracking. The forums are not a reasonable substitute. Too often things are reported but not immediately addressed… then forgotten for months or years (justification for text editors, anyone?)
The good news is that there are many folks here eager to contribute their expertise to continue improving JUCE. Let us help you help us.
amen! this is so spot on with my own impressions lately, personally I also think it’s frustrating fetching new commits only to see that correcting typos in documentation has been a priority when the “house is on fire”. (Don’t get me wrong, I love the way JUCE is well documented, but you should make sure the code below the comments actually work the way they are described first)
yes, one of the thing that i don’t like in the new way of managing juce releases it’s the usual slow down of development to a complete freeze in silence for some weeks, that ends with seeing a new version on the horizon with things that were not on the radar (and broke the actual workflow and tons of other stuff in the middle).
Again, this need serious thinking on how QA is done internally.
Why on earth we have only the master branch ? why don’t you publish your new features and changes in PUBLIC branches and merge them when they are really tested and stable ? this way for example if i want to use or help with the new multibus thing i just checkout a branch and mess with it, but i’m aware on the consequences of doing that. before merging back to master things have been discussed, tested, improved and bugfixed, in general have settled.
Another big problem is that the new features come before fixes.
Since JUCE 4.1 came out there was a show-stopping regression - that the demo plugin was broken in AU in Logic X. This is without any multi-bus stuff, just a regression in the stuff that always worked fine before. When the fix finally arrived at the 4.2 commit it came with all these other changes so now people who waited for it still can’t use it. I think that it will be good to prioritize fixing regressions before adding more features.
We hear you! As the product and our community grows, it can be challenging challenging to keep up with processes and quality. Please believe us that we are doing the best we can to improve on this. I know it’s extremely frustrating to end up with code that does not work and your product breaking because of bugs in framework code that you are used to just rely on. We are preparing bugfixes for all the stuff that was posted here in the last couple of weeks, and hope to release it as JUCE 4.2.1 as soon as we can.
This suggestion makes a lot of sense. We definitely want to get into the habit of announcing major breaking changes in advance. There is also the idea of putting some kind of public JUCE roadmap online, so you will have a better picture of changes to come before they happen, and can give us feedback on it.
Yes of course you are right, we should not release untested code. I think this is quite obvious and I hope that something like the untested AAX thing will not happen again. The major problem with all of it is this: there are so many combinations of DAWs, OSes and plug-in formats that the required testing would keep us JUCE developers busy all day, and there’s just three of us at the moment we are recruiting developers by the way! Also, hopefully one day we’ll have a full-time tester here who also has all the relevant dongles ready
Yes we wanted to do this for a long time. We couldn’t, because we had to deal with the closed-source Projucer and different repositories that had to be merged together to release 4.2. Now as we open-sourced the Projucer and factored out all the closed-source stuff into a DLL, this restriction is gone. So expect us to introduce those different branches very soon, after this bugfix release is out of the door!
Yes. Related to that, what we also want to do now is to put a list of official technical requirements on the website. This way you will know exactly what OS versions, plug-in formats etc. JUCE actually supports (= you can also expect us to test those). Hopefully this way there will be less confusion about it in the future.
Yes I’d love to do that and I think it is very much required for a project of the size of JUCE. Most people seem to agree that it would be better for everyone to have such a system.
However, deciding on a system and then actually setting it up is quite a lot of work that we have to squeeze in with all the other things. But expect us to come up with something relatively soon.
As always, big appreciation to this community for all this valuable feedback and for helping make JUCE better!
Sorry Timur, I appreachiate the work of you and the team very much. But as it is done now, you can’t sell that as a release. It’s just another button to press, a Tag set in the repository. To make it a release, do additional testing with that specific version. So what really needs to be done is to define tests to be made before releasing and document them. This would really make a release worth talking about.
It’s also for the marketing important to have a differenciation between bugfix and release.
That’s another part of the problem: don’t test yourself. A developer is in 90% unable to find things behaving strange, because he/she test’s with an expectation. The best would be to hire some students for that. They can work cheaper and gain an experience in return, no school in the world can give.
That way you also get development resources back.
The abstraction layer from the different hosts and SDKs is the major feature of JUCE (at least for me and I think also for the most of us). If it was only one platform, I probably would work on the SDK directly and choose any arbitrary GUI widgets. I know, there is a lot other benefit in JUCE, but the abstraction is absolutely unique AFAIK.
As long as it’s more stable than the api docs and it’s search bar SCNR
I am thankful for your statements, it really sounds like the processes inside Roli will make a change and I am really looking forward to the things to come.
@daniel: Thanks for the feedback. I am very much aware of proper release processes, documentation, having dedicated testers on the team, and all that. I have worked on software projects with big teams where all of that was in place and actually enforced. However with JUCE, we are a very small team, having to quickly react to changes, and it seems that we have not yet found the optimal way of dealing with all that. This discussion right here is actually very helpful in this sense!
Also, yes with 4.2.1 I meant just a tagged bugfix release, not a major one, that was probably a linguistic misunderstanding.
I knew, that’s probably too many words, I didn’t mean to be intrusive. And you are right, if you look at the project it is almost incredible, that you acomplished all that with that small team.
So reduce my too long post to the idea, to use cheaper testers to free development resources.
About the release, I just wanted to point out, that it is not transparent for us, what happens inside Roli, if a commit is marked as release, as bugfix or new version. I know, what I wrote is a very idealistic version, but maybe you can use that as ideas to market your releases (like “see: for that release we tested these hosts, these features and what else…”).
Quickly setup a temporary bug tracking system (could be the one in GitHub for example).
Having a TEMPORARY one will allow you to better understand what the real needs are in the case of JUCE.
Also, being explicit that it is a TEMPORARY one, you will save the complaint regarding lack of functionality, etc.
Let users test 4.2.1 and populate the bugtracker with bugs that have been found/remained unsolved
Fix all those existing bugs publishing the commits, so that people can confirm it is fixed.
When all those bugs are fixed, test it, mark it 4.3, then go on with new features in your backlog (at that point, the bugtracker will have had its field testing done, so perhaps the best you could do as a “new feature” is to adopt a official bugtracker if the one used until this point proved to be lacking of some important feature)
Hi, I’m a newbie at Juce, but in my main job working in release engineering and build automation…
That said, some ideas @roli-team
I think you have a lot of experienced developers.
It is a waste not offering them a developer branch to test upcoming changes.
Only if all the “old hands” (I think you know them well) give positive feedback, you should consider this a release.
I propose this additionally to a proper release process.
Introduce a bugtracker quickly. And best also a Wiki.
Don’t hesitate, you can waste years with tool selection.
Better start with something than nothing.
E.g. I’m using Jira and Confluence and you will get them for free as an open source project: https://de.atlassian.com/software/views/open-source-license-request/
A lot of OSS projects use it succesfully.
Introduce a CI server for all branches and pull requests.
E.g. Jenkins is easy to set up and will verify all pull request of compileability.
This helps in faster including users proposals and motivates them to bring in some.
I know you might know all of this and I really don’t want to be precocious.
But sometimes the outside view of a newbie might be helpful.
Just my two pennies worth … and sorry for continuing the OT discussion.