`juce7` technical preview branch

Hello everybody.

We’ve recently published a new juce7 branch on our public repository: https://github.com/juce-framework/JUCE/tree/juce7

This branch will contain a preview of features that will be included in the initial JUCE 7 release. We will be adding features as they become ready, and we encourage developers to try the new branch and let us know if anything isn’t working for them.

Initially the branch has some changes to macOS graphical rendering.

  • Asynchronous rendering is enabled by default
  • We now cap the redraw rate at the physical screen’s FPS which improves interaction with Apple’s adaptive screen refresh
  • The cap on FPS inside plug-ins has been lifted
  • We we have added a new Metal-layer backed rendering option that addresses the following issues with Apple’s display area invalidation:

On all platforms we now use a new cache of GlyphArrangement in side the Graphics class that makes rendering GUIs with a lot of text quicker.

We will also shortly be adding support for hosting and authoring LV2 plug-ins, and support for Audio Random Access (ARA) within JUCE.

The launch date of JUCE 7 is not yet fixed in place, and it will depend upon the testing of our new features. We hope to have everything ready inside a couple of months. JUCE 7 will be same price as JUCE 6, and will feature the same pricing and discount structure.

We also intend to include better unicode and emoji support as part of JUCE 7, but this won’t form part of the initial release. We will publish more information when we officially announce JUCE 7.


Amazing!! All of these planned features sound awesome, and are super exciting!

Have you considered integrating the CLAP format as well as LV2? There’s an example CMake integration here.


At the moment adding CLAP support doesn’t add much value to JUCE users. This may change if CLAP becomes more ubiquitous than the collection of other formats already available in JUCE, but until then it’s unlikely to be a better use of the JUCE team’s time than things like accelerated GUI rendering, improved webview integration, better unicode support, a decoupled editor/processor architecture, and any of the other highest voted feature requests.


Windows graphical rendering enhancement on Windows as well planned ? (like Direct 2D support or whatever works better)


Yes. We’ve been following this thread:

At the moment text rendering is slower using that D2D renderer implementation, which drags down any broader speed improvements. We will reassess the situation when we have improved our unicode and emoji support, as that might change the balance.


That 's great – But I would have preferred CLAP preliminary support instead of LV2 which in my opinion does not have much future now that CLAP is hapening, and is a weird plugin format (with all those annoying ttl files that have to be generated). Are you re-using some of the lv2 wrapper from @falkTX ?


I have a question, how long will the support for version 6 be (bug fixes)?.
before, when Roli, the version you bought if it had bugs did not solve them and forced you to buy the next version. Do you have any plan to maintain LTS versions or something similar? I think it would be a great success, even if I had to pay extra to keep an LTS version.

PS: Congratulations for the new JUCE7 :slight_smile:

No, none of that code was used.

We have no plans to maintain LTS versions.

JUCE 6 will not be updated to remain compatible with the latest versions of operating systems or other libraries and frameworks. If there is a particularly critical bug, that we don’t already know about, that renders JUCE 6 unusable on the current set of supported deployment targets then we can grant special permission for JUCE 6 users to apply the corresponding fix from a JUCE 7 commit. This will be the exception, rather than the rule.

If you would be willing to pay for an LTS version, why not pay for the next version of JUCE?

1 Like

Oh this is fantastic. I’ve wanted Emoji rendering every since i moved of vstgui. Thanks!

And, not wanting to hijack this thread with CLAP related discourse, if anyone here does want to work on porting their juce 6 + cmake plugin to CLAP, start a new thread tagging me here or hit me up on TAP or surge discord or the clap GitHub - the extensions ben linked are closed source compatible and work for several synths.

The one thing I’ll say is “I wanted surge to have both emojis and clap” and “surge now has clap” because emojis are super hard - can’t wait for that feature!

Very excited for juce 7. Thanks as always for the awesome work @t0m and team!


After switching to JUCE 7 I see no issues at this point. I compile with “Treat Warnings as Errors” enabled.

I’m on Windows 11, Visual Studio 2022, and using Tracktion Engine.

1 Like

looking forward to check that out

1 Like

To be honest, I was hoping Juce 6 would have more useful features or longer support in time. Or Juce 7 a good feature set, like a proper replacement for OpenGL (Vulkan). Anyway, if your Direct2D implementation works without the problems that @reFX mentions here, maybe it could worth the price.

But for just faster text rendering and some OSX improvements (I’m on windows only), it barely justifies paying 800€+VAT again (even with the 30% of discount)

1 Like

If you have several products in the market, and you have to update the “breaking changes” of a new version for all the products, it is a very arduous job that takes money and time.


– Is it possible to get hints to the commits which add these features? I’m excited to test it out since I just recently went through this entire part of the pipeline with a fine tooth comb.

I think JUCE 6 has a very respectable set of features.

However, the bulk of the work contained within the scope of any specific JUCE version is maintaining compatibility with new features of operating systems, DAWs and plug-ins, or improving our existing infrastructure to work better with them. I think our Indie tier in particular offers excellent value for money. For that price, in addition to any new features, you get the JUCE developers working constantly to ensure that your software continues working on the latest versions of all the supported platforms. If you would prefer this arrangement on a rolling-contract basis, rather than a series of one-off fees, you can sign up for a subscription licence.

We also add both major and minor features to a specific release beyond the initial launch. We will publish more information when we officially announce JUCE 7.


We work very hard to maintain backwards compatibility, and we only make breaking changes after careful consideration. Most breaking changes are to fix underlying problems.

1 Like

They are the first set of commits on the juce7 branch. It should be fairly clear what each of them relates to.

Hey devs!
Happy to read that JUCE7 is on the horizon.
I’d like to bring to your attention that with the current windows rendering, there is a need for repaint throttling too.
The reason is, that external influences can lead to a lot of unnecessary repaints per frame, with brutal effects on rendering performance even if the plugin gui doesn’t do any much involved rendering. I’m talking about freezing DAW guis, it quickly gets worse if multiple plugin windows are open.

In particular, these two scenarios are easy to reproduce:

  • moving sliders with the mouse
  • ui elements being updated due to automation attachments

In both cases, the issue is that the windows message system can easily send many more WM_PAINT calls than would be necessary for a single frame. Those follow directly on InvalidateRect. If you have one of those high dpi mice, they tend to send more moves per frame than your typical screen refresh rate, and automation is tied to buffer size. I was able to observe InvalidateRect > WM_PAINT successions exceeding 200 fps, each time causing actual paints of the involved components.

The fix I implemented will queue invalidated rectangles up to a specifieable max delay (10-15ms works well), before handing them over to windows via InvalidateRect. So this is one way to do it with the existing rendering. There is no way to sync to screen fps which I know of, that GDI winapi stuff is super archaic, but as long as you always send the first invalidate immediately and only apply queuing/delayed invalidate afterwards, it still feels responsive enough.

I’d welcome it to see a mechanism like this in JUCE7 (as long as there is no new renderer for windows), because currently it is the only reason for me to carry around and maintain a modified version of JUCE.


1 Like