I've been using a several-months old version of juce, because I bumped into badly-broken Pro Tools automation in the Juce code that comprised the late 2014 tip code (I still don't know if that's fixed). But I've just grabbed the tip code and crashed into this new AudioProcessorParameter class. It may or may not provide some benefits, but it's going to take me quite some time to sort out. But it raises what I feel has been a real issue with Juce. And that's the haphazard way that it changes.
I'm sure I'm not alone among developers who must pay attention to all sorts of issues. This means that I can't visit the Juce forum every day to see what's going on. A major change like this parameter class can slip right by. When I try to bring things up to date, I find that there's often a very unwelcome period of changing things that worked just fine before. This can blow a schedule right out of the water.
I do appreciate how much effort goes into running a one-person company and I really hope that the new association with Roli can provide some relief. But I would really appreciate a newsletter whenever you feel a milestone has been reached. And I'd also love to see release notes that indicate what has changed and how we can bring existing code into compliance. Your license fee has been more than reasonable, but I've got to say I wouldn't mind an increase if it could help those of us who find Juce to be an important part of our business.
I disagree, the audioprocessorparameter class has been very useful, okay fair enough, i had to spend 20 minutes to incorporate the changes, but i feel the changes that was required helps customize each parameter.
when we work on development/tip versions we should expect changes right?
you should keep an old version of the current tip for your current projects while you get used to the new stuff:)
JUCE is in a sense bleeding edge; I am not sure what you’re expecting… But onqel said it right.
Since the library always has the iron running hot, as soon as you update your local clone, it seems fair to expect to have to test the new features against your code. JUCE is quite community driven, afterall; always lots of new stuff and changes, and much testing is done by users. It can be tedious going through the commits to see what can affect your software; but that’s how it is.
Since youre saying the new parameter class addition breaks your code; why not at least say why/how it breaks so it can be fixed by someone? You know the drill, no doubt. Likewise for your automation issue/blocker.
I agree with "Mikey." If a change will break existing code, it would be great if it was documented in a changelog, that is distributed with the build. An example of how to use the new code would be nice as well (i.e. how to bring existing code into compliance).
"Bleeding edge" is all fine and dandy, but when you have a significant legacy code base, and need to rebuild every now and then to deal with new plugin formats/whatever Apple has broken this time around/etc., documentation on how to update older code is a good thing.
I should note that I just updated one of my plugins from 3.0.5 to the latest tip, and it took me a few minutes to get things building properly (except that the font in my TextButtons isn't behaving properly). However, this doesn't mean that others won't run into issues when updating to the latest code base, nor that these issues are OK just because I'm not running into them. I've certainly spent many days tracking down undocumented or poorly documented changes when updating from one version of Juce to another.
EDIT: I should add that these undocumented changes sometimes work in my favor. For example, something changed in 3.0.5, where an older version of 3.0.5 was not compatible with AudioSuite for AAX, while the later version of 3.0.5 worked with AudioSuite. However, this change was not documented or called out, and happened within code that was supposedly the same version number. These are important details!
I'm not asking for no changes. I'm asking for notifications, release notes and porting strategies like you'd get with just about any other API. It's extra work to be sure, but it's reasonable to ask for. Just tossing in changes--especially when they break APIs--is more a hobbyist approach.
Well, Im not sure about the subscribe thing, but you can “watch” respositories on GitHub, which can get you email notifications on commits and pull requests.
I've previously expressed a desire for more meaningful versioning in JUCE. Historically the version numbers change in a fairly arbitrary way that does not convey information regarding stability or API breakage from version to version. Whether full Semantic Versioning is necessary or desireable is open for debate, but there is certainly room for improvement in this regard.
I would also very much appreciate JUCE considering a workflow that separates stable (release) and development (tip) branches. GitFlow is one possibility. Right now, there is no way to identify "stable" points in the repo. And it is not always desireable -- especially if you have more than a few projects at different stages of their lifecycle -- to keep everything on the tip.
Thanks guys, all your comments were read and taken on-board! We're working on an all-new website at the moment, and better change reporting is something we'll be focusing on.
Just to chime in here, not wanting to moan but, having just updated to the latest tip this evening, spent a while trying to work out some compiler errors due to some of the virtual functions in ValueTree::Listener having some added (very useful looking) parameters. I didnt think to check the commit messages which would have saved me some time... I'm still a little green with C++ and virtual / pure virtual stuff so I didn't know where to look to begin with... also the online documentation is not up to date with the latest code.
Would be good to have a clear system to check for breaking updates such as these.
Also looking forward to what JUCE and ROLI are cooking up in the background. In general feeling really positive about being part of this community and project. >>>>
EDIT: Just read the announcement from 5 hours before I posted this!!! Doh!
Just to echo what Jules said, it's been duly noted!
Sorry to hear we broke your workflow Mikey. We can't guarantee it won't happen again - it certainly will - , but there are a few things we will do to make it easier for you in the future to flag breaking changes happening to the code.
