I’d just like to restate that the recent lack of attention on the forum is temporary.
The JUCE team’s annual leave has been very compressed this year, with only a handful of non-locked-down summer weeks available, so we’ve had much less bandwidth than usual, and will continue to have less bandwidth for another few weeks. We’ve also been organising ADC. As suggested in this thread we have a team that helps us run this, but moving to an online-only format has required lots of new procedures and infrastructure. Whilst this has taken time away from JUCE development this is something we absolutely want to be involved in. We think it’s particularly important to the audio development community (and we created it!). Without our involvement it won’t happen.
Quick plug: ADC talk submissions close midnight today: https://audio.dev/submit-a-talk
We also have no plans to grow the team aggressively. We believe that the best way to remain stable and focused on features that deliver value to our users, rather than working on things that will maximise revenue, is to have a sustainable business plan. Taking on debt to finance growth regularly destroys companies. As I said before JUCE is in a much better position now than it has been in years. Stability is a valuable feature for projects that depend upon JUCE as a piece of infrastructure.
Of course if you are depending on JUCE then it’s also good to have feedback on its direction and what work we’re prioritising. The Feature Requests section seems to be taking a bit of a hammering, but we added something like 7 of the top 10 to the JUCE 6 release. The votes there are important. A highly voted request doesn’t mean that we’ll actually implement something, but it is still useful to measure the kinds of things JUCE users are thinking about. The same with the survey. Labelling it ‘marketing BS’ is disingenuous. If we look at the top 5 for paying customers (a slight difference from including everyone)
-
GUI rendering performance
-
DSP libraries
-
GUI widgets
-
Plug-in features
-
Build systems integration (CMake etc)
we included 2) and 5) as major features of JUCE 6. 4) is a little too vague to pin down but we have certainly been working on things there, like parameter groups. 3) we did things like making parameter attachments much more customisable. 1) It’s not for lack of trying. We re-wrote our rendering engine to use Skia, which we had hoped would bring a nice performance boost at the cost of a little extra configuration, but it delivered quite lacklustre gains for a massive implementation headache. We’re working on something else but it’s still too early to broadcast any results.
We know we could do better with issue tracking. With our recent reduction in bandwidth we’ve been less responsive on the forum, but there are also much longer term things that have slipped through the cracks. We know it’s very frustrating. @jpo’s reference is a good example of that, which has stalled because we probably need to buy some hardware to address it. However, most of the things that have slipped are not impactful bug fixes. Please don’t reply to this post with a tsunami of examples of unaddressed issues - I’m certain we’ve missed stuff over the years and we’re well aware that this is an area we could do better in. However, we will prioritise development on things that maximise value. In addition to experimenting with graphics rendering approaches we’re currently working on MIDI 2.0 compatibility, as this will become an issue when Big Sur launches (probably this year), and on making JUCE-based software compatible with the OS’s accessibility APIs.