JUCE Announces Acquisition by PACE

This announcement can also be found on the JUCE website.

Initially released in 2004, JUCE became part of ROLI Ltd. in 2014. Under ROLI’s leadership, JUCE evolved into the primary framework for developing cross-platform audio applications. ROLI also worked with the JUCE team and the vibrant JUCE community to create the Audio Developer Conference, the foremost meeting of audio software and hardware developers.

Roland Lamb, founder and CEO of ROLI, said, “It has been a pleasure and an honor for ROLI to be a steward of JUCE over the last six years. We’re really proud of the work we’ve done to build the framework, grow the community and start ADC. I believe that PACE will be an ideal new home for the framework and the conference. They have a strong track-record of serving developers with essential tools, and Allen is a true technologist who has the leadership vision and technical understanding to help take JUCE to the next level.”

PACE specialises in software IP protection and secure licensing, and has been making developer tools for software creators for over 35 years. As PACE’s tools are used by a large number of world-class audio software publishers the company understands the importance of JUCE as a foundational piece of industry software infrastructure.

“I’ve always had the utmost respect for Jules, his work, and the team he’s put together,” said Allen Cronce, founder and CEO of PACE. “The JUCE framework is very important to the pro audio community and our customers. We’re happy to give the JUCE team a new home and look forward to supporting their continued efforts that make JUCE a world-class application framework.”

This acquisition provides JUCE the opportunity to grow further within an entirely developer-focused company, to execute on an ambitious roadmap and continue to serve the needs of the audio developer community.

Jules Storer, founder of JUCE, was closely involved in the process. He said, “ROLI has been a great home for JUCE, helping it grow into one of the most important tools in the audio industry… However, that importance also meant that it began to attract some acquisition offers! Of the many companies who expressed an interest, PACE came out tops for us in terms of what a good owner of JUCE needs to offer: their culture is completely developer-focused, they’re a neutral company who are in the licensing business and already have relationships with many JUCE customers, and their motivations for owning it align with those of the JUCE team.”

“We’ve been impressed by the depth of the technology they’re working on, and we were all very happy to give the go-ahead for this. For me personally, my day-to-day schedule won’t change much - I’ll still remain at ROLI, mainly working on SOUL, but also advising the JUCE/PACE team.”

Both PACE and JUCE benefit from a thriving ecosystem of audio developers and tools, and JUCE remains committed to helping the entire community to learn from each other, share ideas, and create world class software.


What changes does this acquisition imply for the roadmap of JUCE as a framework?

Who, of the current staff, will move to the new company and will keep working on JUCE?

Now that Jules and JUCE are separated in two different companies, who will be the… “Linus Torvalds” for JUCE, the person who has the last word when deciding what goes in and what doesn’t?


first and foremost, a name that’s made of four capital letters :grin:


The acquisition will have absolutely no bearing on the overall direction of the roadmap, but it does mean that we can do much more exciting things. Both myself and Ed are remaining with the framework, and one immediate, substantial, improvement is that we’ve been able to add @reuk to the JUCE team! This gives us loads more bandwidth to develop JUCE features.

In terms of governance the JUCE team is much less dictatorial than the Linux kernel. When it comes to decision making the users of the JUCE forum and the wider JUCE community get an implicit vote too. Jules has only been contributing in an advisory capacity since he began work on SOUL and there will be no change to that arrangement.


Congrats. I can say from personal experience of working closely with PACE for many years that I would expect the partnership to be a great success.


ok, but let PACE be aware that we will be vigilant and look out for any introduction of american spelling in the library


So can JUCE be more open and actually accept pull requests now, like other open source projects?

Very often there are very simple bug fixes or minor feature additions, but they are never merged. It always has to come down to one of the official maintainers doing the work, and often it’s just a minor style change that not a single customer would care about.

We would love to have a true “development” branch that EVERYBODY can contribute too, not just the “elite” with right access.


I must say I agree with this. I’ve always found it disconcerting that PR’s have to go through an invisible process before appearing on develop. It would be nice to have more transparency, and involve contributors more. Most PR’s on the JUCE GitHub look like they’re being ignored, which is not encouraging for other potential contributors.


I have to disagree on that one. As a user of JUCE I would be worried, if adding user contributions would be taken too lightly. It is so easy to break things, given the multitude of environments, hosts, OSses, plugin SDKs…

I think any contribution should be discussed beforehand on the forum to see, if that idea actually suits the direction the framework is heading. Surely you can already add your pull request to that discussion, but I think it makes more sense to clarify the needs and the strategy before starting to work.

Keeping the API concise is an asset that all users benefit from.

If you want to create a peoples-branch where everybody can push to, you can easily fork. But expecting the juce team to check and add any contribution would be a big ask.

In my experience the JUCE team was great in addressing and explaining their reasoning for and against the changes, even with the limited resources at ROLI.
Surely sometimes things get lost on the way, a better and more transparent tracking system than the forum would certainly something to wish for. And surely, the answer is not always what we wished for. But they usually give a viable alternative.


I’m relatively new to Juce, but I wanted to weigh in a bit here too.

As paid software I think it’s expected that the team take ownership of core development, triaging reports, and bug fixes. The community has a critical role in identifying and reporting any problems and making feature requests. Opening up a development branch to everyone for a complex audio processing framework is probably going to create far more problems than it will solve for most people.

If you have an exciting new feature (or improvement, or fix!) you’d like to share with the world, I think it’s a great idea to introduce it on the forum.

1 Like

Time and again the JUCE forum has proven its worth. There are many talented people here who generously give their time to help and educate all of us. And this is first stop for getting help with an issue. How many forums do you visit as often as this one?

And, the carefully monitored and considered changes to JUCE are precisely why it is as good as it is. Jules created something great that all of us benefit from. And, he and the rest of the team have continued to maintain it, and move it forward, in the same spirit.

I vote strongly for the status quo.


And our experience is the exact opposite. Roland posted a patch to add a new feature to Dropdown-Menus (column-breaks). It was completely ignored. Not a peep from the JUCE team about a full implemented and tested new feature.

I’m quite surprised by some of these replies and the tone in them. You’re basically saying that extremely experienced developers like Sound Radix and us (reFX) are somehow not good enough to create pull requests and have them reviewed. Nobody was asking for blindly merging everything.

How is the forum a better place? GitHub has a specific process with its own “forum” for each pull request and issue, which surely is MUCH better suited for the task.

I really can’t believe the resistance to an established and time-tested process in favor of unstructured shouting into the wind. You have to be kidding me. You are here to learn something? Great, how about learning the right process, tools and letting other people contribute?


Hi, Tom.
Are you still the leader of the JUCE team? I mean, are you and Ed still remain in ROLI, or together moved to PACE?
And is reuk originally work in ROLI or PACE?

1 Like

Minor style changes are precisely what a lot of JUCE customers do care about. One of the pieces of feedback we always get about why people use JUCE is its consistent code style and how easy it is to dive into the source code and, as an open-source commercial library, this is one of its main selling points.

In an ideal world, yes, everyone would be able to contribute to JUCE and help the library grow, but the reality is that the majority of JUCE PRs need to be completely rewritten to go into the library - people rarely match the style guidelines and it’s unlikely that the changes have been tested thoroughly. Even when they are tested it’s hard to reason about how minor changes to the internals of JUCE can cause issues in the rest of the library - even we’re bitten by this sometimes and we work on the internals of JUCE every day!

And then there’s the issue of maintainence - who maintains the code once its in the library? Are PR authors going to stick around to answer questions and fix bugs in the code they’ve submitted? In our experience that’s highly unlikely. For us, adding new features to JUCE is a constant weighing up of usefulness vs maintainence burden. Yes, we have more resources now we’re not at ROLI but the reality is that the JUCE team is still small for the size of the codebase, and if we were to merge every PR that we get we’d spend all of our time fixing bugs in them and no new features would ever get added!


Tell you what would be a good outcome though - a public JIRA or similar for it with every bug and change request on :slight_smile:

At least then you’d know your request or submission was definitely being ignored :slight_smile:


Github already provides this.

Best is maybe to clean github one with outdated and won’t do issue/PR and start clean.


Yeah - it’s just there’s a lot of encouragement to use the forum for reporting issues so all the issues aren’t actually on the issue tracker :slight_smile:

1 Like

Ed, Reuben and myself are now employed by Raw Material Software Limited (trading as JUCE), a UK company dedicated to the development of the JUCE framework and ADC. Pace Anti-Piracy Inc is the new owner of Raw Material Software Limited.

We were hoping to make the acquisition announcement in a few weeks, when we could also reveal some more concrete information about some upcoming features, but some of the more observant members of the audio developer community noticed the filings in Company House.

So, now that the news has broken, we would also like to let people know that we will shortly begin working on adding accessibility support to JUCE. This won’t be ready in time for the launch of JUCE 6, but is currently scheduled for JUCE 6.1. Once JUCE 6 has been released we will be reaching out to the community for feedback from people who require accessibility frameworks to use audio software and companies where accessibility support is crucial. We already have some generous offers of assistance from a handful of groups but opening up this process to everyone will benefit the largest number of people.

We will also be making improvements to how JUCE licenses are managed. A new portal where JUCE users can configure their current license, update their subscriptions, and view invoices and receipts for their purchases will replace the limited functionality provided by MyROLI. We’re currently in the process of transitioning away from ROLI’s web infrastructure and will provide a more detailed update when the new services are ready.


I’m still using the forum to get fixes.
We should keep in mind the JUCE team indeed has lots on its head.
However, It would be nice is to have a transparent feature/PR workflow with the JUCE team.

Here are few PRs / fixes etc that got buried (as an example of current situation being less than ideal I guess for some developers, especially for bugfixes)

And here is an example of a post that was fixed while other was buried:

Having said that,
Over the past years, JUCE team really became more responsive to bugfixes. so indeed sometimes it takes less than a week to see a bugfix commited by the JUCE team.