Is it just me or responses from the JUCE team to questions posed on the forum have become quite rare recently?
I’m personally following four topics that have so far failed to get an answer from the JUCE team, and all four impact development of plug-ins in a significant way, at least for some of us:
Some of these require no more than the addition of few lines of code that retains the current default behavior (thus no breaking change) allowing for the desired customization to the developers that need it.
And what’s more worrying for me is the total lack of acknowledgement, no feedback on whether the idea has been rejected (and why), it’s in the backlog, or what else.
If it’s still true that the team reads every post, then it feels like several have been read and either forgotten or silently ignored, perhaps because no one on the team wants to end up being the “assignee” for those?
We’ve been much more stretched than usual over the last few weeks. Moving the Audio Developer Conference into a purely online format has taken a great deal of our time and the JUCE team has also been taking some well deserved time off following the launch of JUCE 6 and the acquisition by PACE. There are a few more holidays coming up this month so it’ll probably be a bit quiet for another couple of weeks.
Please don’t think that the addition of few lines of code that retains the current default behaviour (thus no breaking change) is a magic bullet. JUCE already has far more configuration options than is healthy. A much better solution is to properly investigate the issue and see if it merits a (breaking) change to the default, but this takes time and effort to think through all the ramifications.
it is obvious that the development model of juce as it changed over time is clearly not sustainable anymore. but it seems neither the team nor pace acknowledge that. this is fine.
I was about to say the same thing about the assertions. it’s always frustrating when people say “it is obvious”, but then don’t explain why they believe it to be so.
otoh, it can also be frustrating that things that are important to a given developer aren’t given attention or acknowledged. I certain have my own list of pain points.
I’m sorry to say that this has been my feeling over the last 18 months or so also. To be fair, I don’t think it’s the team’s fault. I think for the amount of development they do and the support people require, ROLI screwed them over on budget and it always felt they were a skeleton team struggling to manage. Who knows if things will improve in the new world, but not holding my breath.
I wouldn’t be so hard with ROLI. Granted not all was positive and I wish the framework had more priority over other projects, but that’s their business decision.
The problem I see is more to ask the people to do everything instead of having dedicated personel.
For instance no dedicated support person who follows up the discussions on the forum and channels that into their roadmap/project management. Or that the developers are stretched out because they run now also the ADC… No wonder there is no time to answer user requests…
i don’t blame the team, but there can’t be just a bunch of engineers to run a project like juce. you need better and clear role separation (no first line support developer organising a conference could be a good start). beside engineers you need QA and build engineering people, FLS team, a technical writer, a product manager with a transparent, public and forward long term vision and clear roadmap items. anything else is just a hobbyists project to my eyes.
While the suggestions of @kunitoki were a bit over the top, there is surely a middle ground.
And to let an external team organise the conference would be a sensible alternative to pausing the development.
I think there are 2 different things adressed by the above posts/complains regarding the juce team’s work.
A- the forum and communication with the community
B- the development of the library itself
A) I agree I would sometimes appreciate some more feedback on the forum when I report an issue or suggest a change. I know the forum is time consuming for you, but we usually don’t expect a long reply.
Anything that shows us that you guys (juce team) have seen the post would be enough. Just an emoticon or a basic standard reply would be great really : “thanks for the report/feedback; ok, we’ll have a look; we added it to our backlog;This seems like a good idea;we’ll have to take a look at that;we are aware of that and we’ll definitely fix it when we have a moment;you can’t be serious;this really isn’t our priotiry;stupid idea; why not, but it’s more complicate than it seems” etc.
B) I personally like how the library development is going.
Previously we’ve seen tons of breaking changes. All the juce4/juce5 changes regarding plugins parameters were a nightmare for instance as I remember it.
So I really appreciate that tom/ed/reuk (if I get the current team right?) are taking the time to carefully think before coding and are not rushing into quick fixes and/or implementing new features.
And the last thing I want is the juce team to have a product manager that would pressurize the dev team.
keep up the good work !
don’t know, qt indie costs the same as juce. and they have plans. they have roadmaps. public ones, i mean. they don’t just disappears for 8 months and then tadaaa!! version 6 is here. they have clear and open plans, clear market vision.
being smart on juce would be to start pushing it not only in the audio area, aka grow the business. lots of people i know they are skipping juce and buying qt licenses just because they see juce “ah but that is an audio framework, i need more for my desktop app”
I’m not sure the best way to go is to try to compete with an established framework with a very broad application surface given you think they are already stretched too thinly. That would require significant up-front investment with no real guarantee of return, probably not what the new owners of Juce had in mind.
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:
GUI rendering performance
DSP libraries
GUI widgets
Plug-in features
Tutorials and documentation
Would be nice to know how / if those are going to be addressed.
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.
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.
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”.
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 ?
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.
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.
