JUCE is getting worse and worse


#1

JUCE is getting worse and worse. I loved it, when it came out, pretty clean and most parts working fine. Then came the ProJucer and all that proprietary stuff which was only half implemented.
Today I gave it a try on MacOS, ProJucer and Demos are crashing, GUI drawing wrong in the demo panel and so on.
It’s a pity.


#2

I agree it’s a pity something like Projucer is needed to manage the complexity of building anything at all. (*) But I haven’t experienced any out of control crashing. (I am not using the proprietary parts in Projucer, though…) If you are seeing a graphics error, it would be nice if you posted a screenshot/capture of that as well as more detailed information about your system.

(*) I know, it’s technically possible to set up everything manually, but it’s a pain.


#3

I have issues with demos crashing as well. It doesn’t create a lot of confidence when you see that sort of thing. It makes me wonder if the creators of the framework (who have millions of dollars in funding) can’t make stable demo apps, how can I hope to create stable apps with the framework?


#4

We’re happy to hear criticism of specific things that we’ve got wrong, but it’s really painful to be criticised in such a vague way, when it seems utterly bizarre to me that anyone could possibly think the codebase from years ago is in any way better than it is now!

As a harsh self-critic, I know that if I was to roll back to an old version of JUCE (I guess you’re probably talking around 2011-ish?), I’d be embarrassed about how astonishingly bad it was compared to the quality of the code now.

And re: the demo, we all run and test the demos constantly, so it’s really unusual for a bug to creep in there - maybe you were just unlucky that you happened to catch it on a bad day?

Not to mention the fact that we now have a whole farm of CI servers constantly running unit-tests to ensure quality of every commit we make. When back in the glorious olden days that you’re praising so highly, there was absolutely zero quality control, and I used to break things all the time, often for long periods before even noticing!

When I started JUCE it was incredibly messy to manually add the library to a project yourself, because there were vast amounts of cpp files and compiler flags, or problematic static lib generation to deal with. After an unsuccessful experiment at putting the whole library into a single cpp file to try to make things easier, I created the projucer and modules, which finally made sense and were widely adopted, and I think it’s a great tool that’s got better and better over the years.

BUT… as well as improving the projucer, we’ve also put in a lot of effort at the code level to make it easier and easier NOT to use the projucer, because we know a lot of people need to work their own way.

Adding JUCE code via another IDE or cmake is far, far easier than it used to be, even a couple of years ago. You now basically just have to throw a handful of cpp files into your project, and bingo. We simplified the module format and documented it to make it clear how it all works.


#5

Pretty disappointing to see this kind of misleading generalised click-bait borne out of a few frustrations or differences of opinion. If you’ve found specific issues how about raising them on a case by case basis with crash traces etc to help move things forward - or even work out what the fix is yourself since the code is often pretty easy to follow and debug - rather than wasting time generating unhelpful froth?


#6

Sorry for the rant, had a bad day and just wanted to check the latest version and wanted it to be good. The supposed GUI drawing error was an erroneous interpretation on my side. Nevertheless some demos crashed in the demo player.
This is not a click-bait because I don’t need clicks here, why should I?
I’m not using Juce anymore nowadays and just visit from time to time to follow its development because I loved it once.


#7

Juce IS good. Reality check - it is easy to understand, easy to use, has a huge number of portable features that work well and make life so much easier than it would be targeting multiple plugin formats on multiple platforms. Plus you get to interact with the developers in a timely manner and stuff usually gets fixed quickly if there are problems (apparently even on weekend and when those interactions are instigated in a spiteful way).

Hundreds of stable, well written maintainable plugins out in the wild being used by thousands of customers in demanding near real-time environments all based on Juce would tend to support that position. But you’ve written it off because you don’t like Projucer and a few demos didn’t work first time? Come on, that’s just unfair.


#8

Something I say all the time : having often this kind of unfair criticism only means one thing, that the plug-in or SDK it is adressed to is becoming more and more popular :slight_smile:

This assumption is backed by the fact I’ve seen recently a lot of new topics with the usual beginner pattern (I was there as well at some point)

I’m trying to do XXXX, but it doesn’t work or I got a crash, that means JUCE is

  • broken
  • bad
  • was better before (that’s a new one lol)
  • buggy
  • not tested enough which is scandalous since I’ve just paid an indie licence even if I know C++ for 2 weeks

(fast-forward in time)

my bad it was my fault because

  • I allocated one filter object only for stereo processing
  • I allocated some memory in the processing function
  • I don’t really know C++ but I do use some new and sometimes some delete (no I don’t know unique_ptr or ScopedPointer either)
  • I know nothing about DSP but I was expecting JUCE to guess what I had in mind so it would be coded magically
  • I code everything like C++ has never existed since C is a lot better and I know C for 30 years, and I didn’t saw I was using the wrong global variable / function the whole time
  • When something doesn’t work, I try to replace randomly the * and & with each other, and as a result the project was compiled but crashed at startup (I still do that)
  • I’ve just find out how to use a debugger and I’ve just seen I did 100+ other things the wrong way since I got a lot of assertion breaks
  • I didn’t read the documentation or samples or API and I tried to figure out something by filling randomly some instructions and calling some dead C++ gurus spirits with voodoo ceremonies
  • It was a bug for real in JUCE (!!!) but apparently it was solved a few years ago, so I updated my configuration from JUCE 3.1 + Visual Studio 2008 to JUCE 5 and VS2017 and now everything is fine

One of the first things I had to learn the hard way with C++ and JUCE is that 99.999% of the time, when something is not working as I expected, that’s my fault and not JUCE / the DAW / Visual Studio / Xcode (well for this one maybe) / the compiler / my computer / fate etc. I still do from time to time the mistake (see my recent new topics) but at least I know I do :slight_smile:

And yes, all the code in JUCE today is a lot better than before, JUCE is a great framework, the Projucer allowed me to sleep peacefully these years without doing anymore any nightmare about projects / header / librairies configuration, and I have a hard time every single time I need to use something else for any reason, since most of the other stuff is not as stable / well documented / easy to understand / well tested etc. During my freelancer career, I had a few times to port to JUCE some projects made with another audio / plug-in SDK, saying they were bad is an understatement (I’m not talking about WDL, never tried this one).

Pro tip for companies : when you ask a freelance developer to code something for you, run away if he tells you he will use his own SDK / wrapper, or any library made for Linux initially and ported somehow to other platforms by university employees / students / interns.

And don’t ask me to talk about PACE :slight_smile:


#9

Ah man, it was all going so well until you swiped at Pace. They’re also really helpful when things aren’t working as long as you interact with them professionally.


#10

I was talking about SDKs, not people, I agree with you at 100% about the guys from PACE :wink:


#11

Not sure why we’re all preaching to the choir here. JUCE is awesome and OP made a mistake.


#12

I’m surprised. I found their SDK absolutely fine. But I’m a bit weird, I loaded the whole thing onto an iPad and read absolutely everything (the documentation and all sample code) thoroughly for around 3 days on holiday at the beach instead of a novel like normal people probably would on their time off. Actually I did something similar with the Juce docs and its sample demos a few years before. I find reading everything up-front like that really helps with something new that I’d rather get right first time.


#13

Well I don’t have the same definition for “absolutely fine” but that’s another topic :slight_smile:


#14

I haven’t tried any older versions, and I started using this a week ago, and it’s been fantastic. So I wanted to throw in a positive experience here too.

Now, what I haven’t tried yet is how easy it will be to turn my (now fully working) VST plugin into an AU plugin for mac. I’m having a friend testing that, so it’s gonna be quite interesting if that process will be a breeze or a nightmare to get going…

But so far, thumbs up from a Win10 user here.


#15

I’m going to try to find a middle point here.
I sympathize both with the post and with the juce team (including its fearless leader :slight_smile: )
To JUCE credit, it might not be perfect but it is still banging on after 15 years and it remains the best solution available to build multi platform multi format plugins. It only gets better. That alone is amazing. Kudos to all involved.
Now to the poster credit, let us be honest: How many of us are still building with JUCE 4? JUCE releases are far from perfect and it is hardly news that projucer or the demos sometimes crash out of the box (in my experience). The “new” (2017) parameter system also took some time to settle and I would need to catch up with the latest improvements to evaluate if it is safe to adopt now. The core is solid but I personally would never risk building my plugins with a new version of JUCE without a good 1-2 months of testing.
So my suggestion would be: how about producing (without rushing to meet deadlines of any sort) a super stable version that doesn’t give any obvious problems in mac or windows? This could do justice to the true might of JUCE.


#16

What parts in JUCE aren’t super stable? It seems like the majority of problems people have with JUCE are due to
a) not reading the documentation or looking at the examples
b) not knowing C++
c) not using RAII or other ‘leak-free’ techniques


#17

JUCE is getting better and better! The Projucer saves a lot of time and is very useful as a central management tool of a cross-platform project (and not just that).

As most people who have written code for over a decade, I’ve read some (a few) code-bases as well and I find JUCE’s code to be very-well written and organized (meant for other human beings to read & understand, first). I learned C++ through that project and I wouldn’t do it any other way!

@jules (and team) - you guys rock! You know your numbers best, but I agree with @IvanC - usually, this sort of criticism signals growth in interest.


#18

When there is one or two problems that are obstacles to a goal it can heavily skew some ones opinion on something and that’s the route of these kinds of posts. I have had no issue with any examples and that’s the general consensus so you have to question if its really a JUCE problem.

On the other hand I do share some other posters frustration with things like UI being slow and OpenGL issues. But studying these problems you find that they come from other frameworks handling naïve approaches better rather than JUCE being worse (can at least make an argument from that as a suggestion for improvement).

Not sure what my point is - give a reason maybe? - 2 cents I suppose


#20

Is it just me, or this thread is actually useless? :joy:
sorry for the bump Jules, but I had to say it


#21

The reason why I didn’t go in deeper to figure out the reason for the JUCE demo crashing was because when I report bugs or issues in the forum or when I suggest them on the GitHub project I don’t always get a response. And so, after a while I just lose the desire to put in that kind of effort to figure out what was wrong.

C++ generally does not make it easy to understand the root cause of why an app just crashed. Especially when it was caused by someone else’s code that uses parts of the JUCE framework that I do not understand. I mean, the reason why I run any demos at all is because I am exploring an aspect of the JUCE library that is new to me. By definition that would generally make it quite difficult to start debugging the code, if I don’t even understand how it works. And in the most recent case it was an OpenGL demo. I know virtually nothing about how OpenGL works so that’s just a nightmare for me to even dream about debugging.