Announcing JUCE 6

No, look under the Tools menu. LiveBuild is there too.

Thanks. I did find an issue. Adding the GUI does not preface any classes with juce:: and projucer now recommends that you leave adding using namespace juce to disabled.

If I go Indie now, do I still have to commit for 12 months, or will it blend into the 1 month commitment once JUCE 6 pricing applies?

1 Like

So, assuming the new repo isn’t under WeAreRoli is this the new repo (deliberately obfuscating link, to avoid confusion) https:// github . com / juce-framework /JUCE.git

Yes, this announced a few days ago: The JUCE repository has a new home

What would you suggest if we’re planning to release in May and have no prior JUCE licence? (only Indie licence is necessary).

I would suggest buying Perpetual Indie licenses for all of your developers now, then upgrading them all to JUCE 6 Perpetual licenses within 1 month of JUCE 6 launching.

This would be exactly the same price as waiting for the launch of JUCE 6 and purchasing JUCE 6 seats directly.


Perfect, thanks tom!

This should now be fixed on the juce6 branch:

Slightly OT but relevant to the potentially increased costs for JUCE Pro: at the same time github has reduced costs massively to the extent that many “Pro” users might be able to use their free tier or very likely their team tier. If you need to talk to bosses about costs (!) then this might help sweeten the pill. But TBH for us we haven’t worked out the details of the change in JUCE costs and Tom’s explanation is very clear and sound very fair!


Can anyone comment on the performance of a WebView approach vs a native GUI approach?

A huge amount of work goes into making web renderers like blink and webkit fast. On macOS/iOS the OS webview will be in theory the same performance as you get in Safari. On Windows it’s a different web engine altogether, either based on MS Edge HTML which is deprecated or Edge Chromium. However, there is added overhead of the inter-op between the javascript engine and your C++. Oh and you have to learn JavaScript :-).

1 Like

Thanks. It seems like the WebView approach would be great for getting things up and running quickly.

Seems current implementation of WebView for Windows will not be able to serve a locally hosted GUI, at least not through http + localhost, see this for details:

Due to loopback limitation in Edge-based WebView cannot be used even as a fallback to Chrome based WebView2, so it would be great if it was skipped altogether in favor of WebView2, or maybe another cross platform solution altogether (like

Another approach would be to patch the WebBrowser component code to allow loading HTML content from string, and injecting / running javascript functions on the already loaded page.

Isn’t it actually very unsafe to rely on a localhost/loopback solution? Any other application can hijack the open ports. Please let me know if I’m wrong.

Another approach would be to patch the WebBrowser component code to allow loading HTML content from string, and injecting / running javascript functions on the already loaded page.

Sounds like the much better solution for me.

1 Like

Not really (you can’t bind to the already open port twice without terminating the listening process). The way you can approach it is to bind a file server hosting your html interface to a random port on every time you initialize the plugin/app, and then your WebView loads the GUI from there. This also allows you to have several plugin instances running on the same machine without interfering with one another.

BTW, I use this http server for hosting the GUI from a local folder on disk:

gone a bit OT here, but i believe that the fact macOS WKWebKitView requires NSAppTransportSecurity “NSAllowsArbitraryLoads” in the host app plist makes running a webserver for plug-in UIs impossible. [EDIT… unless you can serve HTTPS]

1 Like

Will there be support for VST3 note expression in juce6?

1 Like

Does that mean, as far as the free open source license goes, this will be easier to make a package script for vcpkg or MSYS2 MinGW64?