The 2019 JUCE User Survey Results

[t0m]

Hello everybody!

These are the results from the 2019 JUCE User Survey, which was sent out to the JUCE mailing list a few weeks ago.

If you missed out on this opportunity to give feedback, and would like to be involved next time, then please sign up to the JUCE newsletter using the box at the bottom of our homepage https://juce.com/ . Complying with GDPR regulations has shrunk our mailing list drastically, so you may need to re-join if you have not heard from us recently.

The data we are presenting here should be viewed as suggestive, rather than definitive. We’ve bucketed responses into non-paying, Indie and Pro categories, as that makes the results a little more interesting to look at, but there are small segments that are unrepresented here. The shrinking of our mailing list has also introduced some bias, with a number of newer signups being from corporate emails like accounts@bigcompany.com. This makes it likely that the multiple JUCE seats bought by corporations in this manner don’t have a voice. Opening up the survey by making it publicly available could address some of these issues, but we would then have to rely on people self-categorising and preventing people voting multiple times becomes much more difficult.

Anyway, with all of those caveats out of the way, here are the results.

Some questions were open, allowing people to respond however they would like. For these ones the JUCE team has read everything and attempted to summarise any common themes. Some questions only allowed a single choice, whereas some permitted multiple selections.

---

What made you decide to use JUCE?

The overwhelming majority of people responded with comments along the lines of “strong cross-platform and cross-plug-in-format support”.

People with a Pro license had much more emphasis on GUI cross-platform support.

People who are not paying for JUCE were much more likely to have decided to use JUCE for learning or education.

---

What is preventing you from using JUCE?

A few people are not using JUCE as they perceive C++ to be too difficult to work with. Otherwise there were remarkably few meaningful responses.

---

---

1. GUI rendering performance
2. DSP libraries
3. GUI widgets
4. Plug-in features
5. Tutorials and documentation
6. Build systems integration (CMake etc)
7. The Projucer
8. Native GUI widgets
9. Testing systems integration (Google Test etc)
10. Windows support
11. macOS support
12. iOS support
13. Linux support
14. Embedded support
15. Android support
16. Web browser based GUIs
17. The JUCE module ecosystem (a module marketplace etc)
18. The JUCE module format
19. Accessibility
20. UWP support

We have a clear leader here, with a handful of other areas jostling for second place. Of the more heavily voted for options people who are not paying for JUCE are more interested in tutorials, documentation and the Projucer, whereas Pro users have a much stronger preference for build system improvements.

---

Are there any other ways that JUCE could be improved for you?

We had lots of people telling us what they wanted from JUCE. A summary of some common themes is below.

Non paying users:

• GUI design tools in the Projucer
• GUI improvements
• A public JUCE roadmap

Indie:

• Thread safety infrastructure
• Support for precompiled headers
• A GUI markup language
• Billing system improvements

Pro:

• A public JUCE roadmap
• Build systems / JUCE static library
• Fonts and rendering

---

---

---

---

JUCE users are primarily focussed on desktop apps and plug-ins, but the percentage developing mobile apps and software for embedded devices has increased over the last year or so.

---

---

---

This is a question we’ve had some experience with via the forum. Whilst JUCE attempts to remain backwards compatible as much as possible there are times when we need to make improvements to the API itself. This inevitably leads to some grumbling, which is understandable when people are forced to make changes to their code to keep pace with the latest version of JUCE. However, we need to change to move forward. Something we’ll be doing in the not too distant future is to make ownership transfers into and out of the API much more explicit, using standard C++ features like std::unique_ptr. The responses to this question provide a bit of reassurance that the JUCE community supports such endeavours.

---

---

---

Rather remarkably most people who completed this survey have also posted at least once on the JUCE forum. I suspect there’s a bit of a bias here involving the personality of people likely to have filled in the questionnaire, but it’s a nice validation that a very large fraction of JUCE users have contributed in some way.

---

---

---

---

---

[fireplayer]

I must say, that is a good survey with plenty of information. Most surveys are usually a waste of time. Well done, people.

[ans]

Kudos. Great example of transparency.

I’m a bit surprised to see GUI performance at the top. IMO the UI is pretty darn fast and snappy compared to others. Is this complaint mostly because of audio-specific renderings, like real-time waveforms, level meters, playheads, and such?

[RolandMR]

GUI performance really lags on 4K+ displays. That’s a lot of pixels to push around on the CPU.

[adamwilson]

Even on small displays, especially for smooth audio-responsive graphics, OpenGL is generally the way to go, rather than using the JUCE graphics classes. Thankfully JUCE provides pretty good support for GL.

[fiedleraudio]

Then again, Apple is dropping Open GL …

[adamwilson]

Indeed, so the next logical step is support for Vulkan (or Metal).

[luisvaldivia]

Please, the support for OpenGL is awful!. You have to fight against a lot of bugs all the time, f.e. scaling doesn’t works correctly for 4k or highDpi displays. If you have any problems there is no reaction from developer team. And Vulkan support should be actually urgent. Working with Juce and OpenGL could be described as „trapped in purgatory…“

[otristan]

So metal renderer on Mac and out of the box CMake support ?

[yairadix]

Are folks who are still on JUCE < 5 categorized as Non-paying? I suspect that would be a very interesting group to pay attention to.

[t0m]

They’re broadly similar to the Pro category, but too few in number to present anonymised results (in the same format) that are not misleading.

[wavesequencer]

Is this complaint mostly because of audio-specific renderings, like real-time waveforms, level meters, playheads, and such?

In my case yes, but only because I didn’t use Open GL (as it seems a little complicated).
I would love it if there were some basic built in hardware accelerated common audio/synth related GUI components/windows such as oscilloscope/FFT/Spectrogram/level meters/Filter curves/EQ plots. Just drawing multiple level bars that update at 50 Hz seems to take a lot of CPU.

[midiculous]

I would be happy if there was just SVG support for Shadows and inner Shadows and some sort of enhanced GUI designer that doesn’t take forever to nudge objects and see immediate results.

[paulfd]

Thanks for interesting results! I missed it but signed up for the newsletter so not all is lost

Concerning API evolution, one thing to consider is that we can now have pretty strong refactoring tools developed. To illustrate this you can refer e.g. to abseil’s approach (https://abseil.io/docs/cpp/tools/api-upgrades). Basically the contract would be “you agree to use our current API in ‘proper’ ways, and we will provide automated refactoring tools whenever we break the API to bring you in line with the current one”. It’s still a bit uncharted territory, but I find it interesting.

[parawave]

Yes. GUI rendering performance.

I understand it isn’t easy and the arguments why it’s not top notch at the moments make sense. But then again I take a look at something like Unreal Engine 4, with which you get photorealistic renderings and million of polygons at 60 fps. Compared to that, how hard can it bee to run a simple 2D GUI?

Now. It doesn’t even have to be THAT powerful. Even some browser engines like PIXI.JS render much more polygons with a much smoother framerate.
Take a look at the bunnymark. Simple 2D sprites. Thousands. The browser isn’t even sweating.
https://www.goodboydigital.com/pixijs/bunnymark/

JUCEs OpenGL isn’t even that bad and much faster than CPU rendering. True. But tell me I can use Graphics .drawImage(…) to render 10k sprites like the bunnymark! Nope. Not even close.

Like the big commercial 3D engines JUCE should get away from too specifc implementations like OpenGL, Metal and handle it like a black box for end users. Okay, if someone REALLY want’s to write custom GLSL or shaders, leave an open alternative.
But if you could provide some basic functionalities most users wouldn’t even need custom shaders.

I think you could resolve a big chunk of this need if there were shader fills AND the possibility to render polygons in a batched way. Some kind of batch that doesn’t split a simple image rectangle in over thousands vertices for each pixel line. (Like the current renderer still does?)

BlurShader shader;
shader.setRadius(20);   

Graphics g;
g.setShader(shader);

VertexBuffer<float> buffer;

buffer.addVertex(Vertex(0, 1));
buffer.addVertex(Vertex(0, 0));
buffer.addVertex(Vertex(1, 0));
buffer.addVertex(Vertex(1, 1));

g.fillPolygon(buffer);

Done. A simple blurred quad. Simple interface. It doesn’t even have to support every single possible Vertex specification. Something with UV coordinates would be enough to draw a ton of UI images. And it could be very expandable if the Shader Fill types of paths or polygons could be user defined. That’s the only place where OpenGL/Vulkan/Metal code must be written.

Providing a concept like Vertex Buffer to Graphics could be incredible helpful and opens a lot of new possibilites. Especially for particle effects and audio visualisations.

[ImJimmi]

Does the JUCE team have any plans to re-run this survey at any point? It’s been almost 3 years since the last one so I imagine there may be some significant changes in the results from 2019!

@t0m

A public JUCE roadmap

This one’s of particular interest to me personally - from the 20 things highlighted as areas to focus on, it seems only a handful have been addressed in the past few years? Would be great to know what the team’s priorities are for the next few major releases - redoing the survey might help highlight those potential future updates.