Has JUCE lost its way?

General JUCE discussion
1

From another thread:

I’m the first to admit that I would rather see 64-bit sample support instead of WYSIWYG code compilation and preview in ProJucer. It would have been nice if Jules had finished providing support for 3rd party modules in the Introjucer instead of leaving it unfinished and jumping to the next new and shiny code toy. But insults are entirely non productive. The best way to be vocal is to be polite but persistent in gently reminding Jules and the rest of the JUCE userbase that there is important work to be done which will directly benefit end-users of software that is written using JUCE (as distinguished from the JUCE customer base, which consists of the programmers).

I’d also like to see better support for native operating system features. Windows 8 has already been released and JUCE is completely unprepared to build applications in the style of this new operation system. Heck, JUCE isn’t even well suited to create native controls on iOS. But badgering Jules about it will likely not produce results.

If you frequent the forums, you will find that one successful approach at getting new features or bug fixes into JUCE, is to simply write it yourself and then work with Jules to integrate it into the library. A recent example is the wonderful outside work that has been done in making the GNU/Linux support more robust.

JUCE has been around now for almost 13 years. Looking over the history of it’s development, it truly is an astoundingly good library. Considering that it was written by one person, I’d say that there is plenty of evidence that Jules has been responsive to customers. The library is unique in that not only does it allow one to build cross platform user interfaces, but it specializes in creating both concurrent audio applications and audio plugins. There is nothing else like it. It is very fairly licensed and priced.

My personal opinion is that perhaps Jules has gotten burned out fixing bugs and adding user requested features and just needed a sabbatical. Especially after the “Jucequake”, our informal name for the massive code reorganization brought about in version 2.0. The Jucequake was a huge success, it ushered in a whole new way of organizing the JUCE source code and also serves as a model for organizing your own source code. This “unity build” style of source code organization was so handy, I had no choice but to adopt it for all my current and future code. Which is quite a rare event because I am quite conservative when it comes to changing my style. Version 2.0 also brought with it the Introjucer which despite being somewhat rough around the edges, simplifies project management across multiple platforms. This is hardly the sign of someone who is unresponsive to customers.

Thankfully, Introjucer is not required for practical development (yet). :lol: :lol: :lol:

Unfortunately we seem to be kind of dead in the water when it comes to significant improvements to the JUCE library. Introjucer never really got finished, and for the last 6 months the answer to most features / major fixes has been that there is “no time for that right now.” Are most of the available time slots for development consumed by Projucer? Maybe. But after 13 years I think a vacation is earned.

I am very interested in specifically seeing more features added to the library and not the satellite system of tools surrounding it. 64-bit samples would be great, more native controls would be great (especially menus). A TextEditor with centered justification. All of the features that have been requested this year that got put off. Hopefully all we need to do is wait for this slowdown of JUCE development to run its course and then we can have the old Jules back.

But if the old Jules is not going to come back for a long time, or ever, it would be nice to have a serious discussion about how we can move forward. It makes no sense to have the forward progress of the JUCE library held hostage to the timetable of a single programmer. If JUCE is going to continue evolving at a brisk pace, I think the current one-programmer model would probably be a bottleneck. We are seeing the evidence of that right now.

It is also unfortunate that a lot of the JUCE folks who I interact with on a daily basis don’t have the fortitude to step up and voice these opinions for fear of upsetting Jules (you know who you are). The chorus of praise in the Projucer thread and the lack of meaningful dialogue regarding delayed features is troubling. If customers cannot have an honest and polite (and I emphasis POLITE!!!) dialogue about their needs and wants, then how can we expect JUCE to evolve to maximally satisfy everyone? Well, at the risk of sticking my neck out, I’m stepping up and saying what needs to be said. I hope everyone can respect that.

2

I have my own thoughts on a lot of this stuff, but really I think it comes down to: 3rd party module support is critical. It’s not realistic to expect JUCE to cover every use case, or to provide every widget. I’ve never used a framework that does. The 3rd party module idea is a great one. I’d probably submit more code to Jules if I didn’t need to worry so much about style. Refactoring classes just to fit Jules’s aesthetics takes the fun out of it, but as a 3rd party module, as long as the code doesn’t plain suck, style is a little less of an issue, IMV. (Much of my code, even on my own time, is developed for my day job, and follows the style I use there.)

One thing I always loved about JUCE (aside from the Java alike readability of the code) is that the classes tend to be rather humble. The component class, despite being a monster, still manages to get out of the way and let me bend it to my will. I used to a do lot of work with Delphi/Kylix back in the day, and both the VCL and CLX suffered from serious inflexibility. If you had any reason to use components, or even the basic panel class, in a way that the designers didn’t expect[1] you were in for an almighty fight. I’ve always personally looked at JUCE as being a bit more of a ‘roll your own’ deal than say Qt, and I’m OK with that[2]. The easy things are still easy, but the hard things are possible. JUCE allows me to build novel interfaces quickly, and for a researcher, that’s huge!

Regards missing features though, perhaps because I’m far outside of the audio world, so I’m more accepting of gaps where I’d like functionality to be, but I can’t think of anything that JUCE lacks that is more than a mild inconvenience at this time.

I don’t think it’s fair to suggest that JUCE is losing its way though. A huge library wide refactor to modernize the code and protect users from memory leaks, whilst also improving efficiency, and reducing code bloat, doesn’t sound like Jules taking his eye off the fundamentals. I was a little on the fence about JUCE 2.0, but having just started making the switch from 1.48, it’s clearly a huge improvement, and a lot of work.

[1] With the exception of the TreeView which truthfully I’ve come to despise. This is possibly the most awkward and un-JUCE-like class in the whole library.

[2] I’m a Lua fetishist however, so take that as it is.

3

FWIW it is probably a lot easier to support your users when your support forum has 9 topics and 46 posts since 2008…

Having now contributed fixes and minor features on every platform I don’t even find the complaints above all that compelling. WinRT is a much smaller port than some of the others, with the big question being - do you use the idiotic extensions and run the risk of getting boned like everyone who listened to Microsoft about CLI, or put a ton of time into COM invoke glue? And I must be doing something seriously wrong, because I have no trouble mixing in native iOS controls!

Seriously, I have the advantage of having written natively on all the platforms being discussed. So I see Juce as a handy toolbox. If I hit a limit or problem, no biggie, just UTSL… For others, mileage will obviously vary.

But my attitude is that ‘Juce’s way’ is wherever Jule’s wants to take it.

4

FWIW it is probably a lot easier to support your users when your support forum has 9 topics and 46 posts since 2008…

Having now contributed fixes and minor features on every platform I don’t even find the complaints above all that compelling. WinRT is a much smaller port than some of the others, with the big question being - do you use the idiotic extensions and run the risk of getting boned like everyone who listened to Microsoft about CLI, or put a ton of time into COM invoke glue? And I must be doing something seriously wrong, because I have no trouble mixing in native iOS controls!

Seriously, I have the advantage of having written natively on all the platforms being discussed. So I see Juce as a handy toolbox. If I hit a limit or problem, no biggie, just UTSL… For others, mileage will obviously vary.

But my attitude is that ‘Juce’s way’ is wherever Jule’s wants to take it.

5

Thanks chaps

I don’t have time to write the huge and comprehensive reply that a topic like this deserves, but a couple of points:

As valley will be able to confirm (as he’s in on the secret), I’m particularly overloaded at the moment because I’m working on a project that I can’t discuss until its launch at NAMM in january, and that’s draining even more of my time than usual. After that’s out of the way, I’ll have a little more free time for you all!

In the last year or so, I’ve had SO many ideas for cool things that I can do with juce that attempting to do them all is impossible, and that’s a frustrating situation to be in. All the stuff that Vinnie wants me to concentrate on would be awesome, I totally understand where he’s coming from, and don’t disagree at all with his stance. But I’ve been forced to pick a few things to work on, like the Projucer, which I think will make the biggest overall impact.

It’s getting to the point now where I need help to keep up! If a “normal” company decided to set up a team to work on something as big as juce, you’d expect to see at least 5-10 programmers being allocated to the task. (I think I heard that Qt had over 100 engineers working on it, and that’s really not much bigger than juce!). Over the next year, I’m going to have to figure out how I can get more brainpower involved, just to keep up…

6

Oh! Wow…well, that explains it! Waiting till January is not so bad.

It’s good to hear this acknowledged.

7

Just let me add that I’ve been more than amazed how well JUCE was kept on its way during the five years I’ve had the honour to witness it. I don’t want to drown Jules in compliments, but I’ve worked in science for quite a while and have talked to many intelligent people, including Noble prize winners, and Jules is really one of the only three people I’ve ever “met” where the word “genius” seems appropriate. That being said, with computer technology moving forward at an ever increasing speed it’s inevitable that a cross-platform all-purpose library comes to a point where it’s just too much for one person to handle. I don’t know if this point has been reached yet, but it will be reached eventually, and I’m glad to hear that precautions are being taken, not the least because JUCE has become my main source of income :smiley: .

8

Cool!! Any thoughts on putting links to your products into your signature? Because I’m always interested in seeing other JUCE applications.

9

Done. I’ve started without JUCE, but switching to JUCE has definitely accelerated the whole thing a lot. Actually, I use your DSPlib in one product as well (contacted you about it one or two years ago) so thanks again for that nice piece of work!

10

Huh, where’s the signature? Anyway: http://www.ddmf.eu

11

Hire someone and let us pay for it. We once had to pay 400 quids for our license years ago, i wouldn’t mind paying that amount every year. We pay 3 times as much for a bpm/beat detection library every year.
I think your license model needs a closer look so you can generate more money with it so it’s easier to hire someone to help you out, although it doesn’t seem to be that easy to find a proper c++ programmer. Maybe TheVinn is looking for a side job, but somehow i don’t think that will work out that smoothly though :wink:

12

That’s a GREAT idea! My company would definitely pay for some of this.

13

+1

14

Excellent point. For PCB layout we spent $6000 USD a seat, and pay $1500 USD a year, per seat (!) for updates.

15

Thanks for your kind words and offers of hard cash!

So far, my approach has always been to concentrate on improving the library and winning hearts-and-minds rather than attempting to make a lot of money from it, and while the workload was manageable, I think that made sense. But it does seem like the time has come to shift things up a gear.

Ideally, the way I’d like to make more revenue would be by increasing the customer base, rather than asking all of you regulars to dip into your pockets again for a license renewal. And that’s why I’m trying to branch out a bit with things like the projucer, which I’m hoping will grab some interest from beyond the audio software world. I might also decide to sell the projucer as a closed-source commercial app, and judging by the amount of interest that my preview video generated, doing so could turn out to be a money-spinner that would fund some extra help.

Re: hiring someone, the annoying bit is that the kind of elite coder who I could actually trust to do this kind of thing would be prohibitively expensive! (Not to mention rare!)

Anyway, thanks everyone! I’m currently using my few spare brain-cycles to try to figure out a long-term plan… Will keep you all posted!

16

whenever i see the svn-shortlog i think, do you ever take a break? I have the fear that you work a little to much.
For me the most important thing is platform support, that anything runs smooth on all platforms. Things like projucer are nice add-on.

We need some creative brainstorming, ideas how other people can contribute their quality work to juce, and how they will be compensated, without stressing jules to much.
Crowd funding etc…

17

[quote=“chkn”]We need some creative brainstorming, ideas how other people can contribute their quality work to juce, and how they will be compensated, without stressing jules to much.
Crowd funding etc…[/quote]

I think that given Jules numerous comments throughout the years, he really is uncompromising on the coding style, commenting, and general simplicity of implementation. It’s probably not so much a matter of finding people to contribute as it is to figure out a way to take whatever code is produced and modify it to suit Jules’ requirements. I can’t say that I blame him, we should not have to compromise on the style of the code in order to have more manpower.

18

You should have said so earlier. “Increasing revenues” is a MUCH better justification for the effort than “a new way to program” (which I have my doubts about). Come to think of it, Projucer for this purpose is genius! Because there are tons of mediocre programmers who will have a hard-on for a tool like this, and they are more than willing to pay.

If you can get people to pay for Projucer as a separate application then by all means do so, especially if it helps accelerate the pace of JUCE development.

19

I love JUCE. My app would not have been possible without it. There are so many awesome things Jules can work on for JUCE. And probably everyone has a slight different opinion on what that should be.

For me it is broad plattform support, especially Windows 8 / Windows Phone 8. The build tools are secondary for me.

I can wait. But it would be great to get a bit more transparency. Answers to questions like will win8 ever be supported? if yes, is this something that will happen next year? With answers to these questions it would become possible to plan my own next steps.

Oh, and I can’t wait till january to see what you have worked on so hard recently Jules.

Patrick

20

Sorry to hear that you are overloaded, Jules, but I have to admit that I am happy you are working on an audio project!

Juce continues to gain traction in the audio world, with a lot of very prominent developers making use of it that aren’t listed on your website (Avid, Universal Audio, Lexicon, Eventide). Any work on your part on an audio project will hopefully fold back into the main Juce code base at some level.

Sean Costello (who just discovered the Shape Button this week)