Is the JUCE team still here?

Looking back on the 2019 JUCE User Survey, a roadmap was the #1 thing asked for by Pro users. (And #3 by non paying). The 2019 JUCE User Survey Results

The other top things ask for were:

  1. GUI rendering performance
  2. DSP libraries
  3. GUI widgets
  4. Plug-in features
  5. Tutorials and documentation

Would be nice to know how / if those are going to be addressed.

3 Likes

They almost disappeared for good, when Nokia dropped them…
They are great, I used them for a long time before I moved to JUCE, and a good friend of mine works there. But you cannot compare them. The better part of JUCE is functionality that doesn’t exist in QT.

Apart from that, everybody is free to choose the tool that fits their need best.

1 Like

i’m not comparing the frameworks. i’m just saying that is a bit reductive to think juce is an audio framework only, and limit the business only in that area.

of course qt also disappeared and popped back upon multiple reacquisitions. but they grew into a mature business: they have a vision https://www.qt.io/blog/2019/08/07/technical-vision-qt-6, they have a roadmap https://www.qt.io/blog/qt-roadmap-for-2020, they have status checklists https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion#State_of_Add-on_Modules, they have a bugtracker (not a forum to track issues and requests).

i would love to see this level of transparency, care and organization in juce.

2 Likes

I am absolutely on your side in terms of transparency and commitment.

It is impossible to know when to work around bugs or shortcomings, if you don’t know when or if at all it might be addressed.
I simply object the view that there must be a huge amount of manpower be thrown into the game (although more is always good, I’m not sure it would solve the issues).

A more formalised view where we can see the status (accepted, being worked on, finished or declined) would be already a huge help, not only for us, but for the team as well.

About the engagement seeking of the user survey and the feature request category (I know I have a religious quarrel with marketing BS), that is always worthless if you don’t commit to address it. Better don’t ask, if you don’t care.

I think I saw one, maybe two issues of the feature request category closed? If you addressed them, make it visible, so we know and can celebrate you for that. I love the process when you link “this is fixed in commit xyz”.

1 Like

I am just new to Juce since 6.0.1. I found juce only with a bit google search for a framework for C++ and Android and IOS compatibility. I will decide to buy a licence in near future.

On Juce homepage I first thought Juce is just for special audio app development …

I think Juce should do better marketing for developer who like to have one framework for Android/IOS app development or for all platforms (including windows, mac and linux). There must be a big market for that C++ based Android/IOS app development.

So I would split the Juce licence prices to a lower price for users without using the audio part and a higher price for users with using the audio part. So Juce may get far more developers paying. More paying developers will get more Juce resources for more support/developers. The reason PACE did buy Juce is not that they start for developing an audio app - or ?

1 Like

FWIW my experience is that the JUCE team is recently more responsive than ever. I suggested a patch for enabling Windows Audio SRC and after a few quick rounds of back and forth the JUCE team has not only took it but also improved on my implementation. And on the way as they were getting into the Windows audio they also implemented another requested feature there. Likewise bugs with Linux clipboard were reported and fixed quickly, etc.

7 Likes

Yes, I’ve noticed your topic was basically their centre of attention for the last commits on the library, the last of which dates to a week ago.

I’m not sure your positive experience is of some comfort to the rest of the developers with pending “requests” for feedback: in a way, it’s like if your report has been put in front of the line and given all attention, while the older ones kept being ignored.

As someone said, switching to a issue tracking system may be part of the solution, BUT on the condition that it is kept up to date and that issues reported there get some kind of feedback in a reasonable time.
If its features help the JUCE team communicate in a quicker way, I’m all for it, and I hope that’s the case because I’d personally like much better the idea of having reports being dealt with in a more structured and followable way than forum topics.
On the other hand, if opened issues end up being stale even there, it’s not much of an improvement (see what has happened for the Feature Request section)

I get that the adoption of a structured issue tracking system has been somehow held back by the idea that there would be a duplication of discussion between the forum and the tracker. IMHO if a forum topic ends up describing a problem, it can be closed and a corresponding issue is opened in the tracker, with a link in both referring to the URL of the other for reference.

3 Likes

Is it just me or responses from the JUCE team to questions posed on the forum have become quite rare recently?

Yes that was also my feeling lately, and I have often hesitated to make a similar post as yours. I now feel it is quite useless to post about the issues we run into, or the suggested fixes to these issues in the forum because they seem to be mostly ignored and it is just lost time (it takes time to make sure that the issue is really within juce, how to reproduce it, try to fix it etc).

It is really frustrating (and my last topic was just a manifestation of that frustration Should the JUCE team buy a Steinberg UR audio interface? )

1 Like

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)

  1. GUI rendering performance

  2. DSP libraries

  3. GUI widgets

  4. Plug-in features

  5. 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.

13 Likes

Thank you t0m for your reply. I have to say I am happy with the way JUCE is developed, I’m not especially looking for fancy new features, although I am happy to use them when they appear. I like the fact that JUCE, while still moving, breaks less often that it did around juce 3. I’m also not a all looking for a full-featured bug reporting website, I’m quite happy with only using the forum for that.

But what has been missing the most in my opinion in the forum those last months was really the feedback. It does not have to be “ok you are right we will do what you say asap” reply, but just some acknowledgement that the issue has been noticed by the team and a hint about your feeling (I guess we all understand that our pet issues are not important for everybody and that you have to decide which ones to pick).

If the “bandwith reduction” in attention to forum posts was known to happen, it would have been nice to be warned beforehand in order not to expect a prompt response in the affected period, or at least to get one such post in reply to topics that were put “on hold” because of that.

It was done in the past, for example regarding the multibus stuff where fabian was the guru: if a multibus related topic was started while he was on vacation, at least the submitter got a “Fabian is the person in charge for this aspect, he is on vacation for a few days/couple weeks and will have a look at this when he comes back”.

With the recent ignored topic/posts, it’s not even clear who in the team should have a look at it to approve/reject/discuss the idea

1 Like

Is there any way this work could be put into it’s own unsupported module? I understand it will never make it in the mainline but there are a few features of Skia that would be useful even if the performance was only the same as the current Juce renderer like skottie

I want to apologise for that, it was more a general statement than aimed to you. I hope it didn’t come across as such.

That is nice, but if these votes are important… can we get more than 3 or a way to get the back/reset the votes? Or has something like that been implemented? To me it looks like I spent my 3 votes on some features a few years ago and I can’t seem to vote any longer and also can’t seem to look up where my votes went.

Edit: I see now I had 5 votes and I can see where they went… but still no way to vote for something else it seems.

2 Likes

Not easily. We took the shortest route to a proof of concept so it’s not appropriately disentangled from all the ComponentPeer, Metal and OpenGL bits.

Another nice feature is that Skia comes with its own shader language, which would work across all platforms. However the future there is probably WebGPU.

I thought you were able to transfer votes, but it looks like the topics need to be closed before the votes are released again. We’ll do a clean up of old requests.

1 Like

For the FRs that are not going to be addressed or seen as value-added by the JUCE team, can such things be closed so as to redistribute votes? Not to say that they aren’t already managed, but I just want to be sure that they don’t stay trapped into the, seemingly, ephemeral void.

You can unvote and use the vote again. But for that you need to be aware of that the FR was actually addressed. Most of the time we have a workaround in place, so we don’t necessarily catch that.
A cleanup would be much appreciated, also for the visibility of your hard work :slight_smile:

How do you unvote?

Oha, I could click on the “voted” and it removed my vote.
But I just checked, I cannot do that any more. Sorry, seems that was false alarm…