`juce6` technical preview branch

Hello everybody.

Following the announcement of JUCE 6

we will be releasing new features onto the juce6 branch of the JUCE repository to allow people to try it out and help shape the release into one that’s best for the community.

Please use this topic to discuss the new features.


The first feature we’ve made public is CMake support.

Since this is a very substantial change it’s helpful to move all CMake-related discussion into a separate thread:


This is awesome! I wished every change to JUCE was going through public review before being integrated into the main branches.

And this leads to my question: what exactly will happen to the juce6 branch in June?

I would expect it to be merged into both develop and master on a commit tagged as 6.0.0, but based on the announcement and the information I could find on the forum, it is not crystal clear.

That’s exactly what we’re planning to do!


We’ve updated the internals of the WebBrowserComponent to the latest platform webviews on macOS, iOS and Windows.

macOS and iOS use WKWebView where available (macOS 10.10+ and iOS 8.0+) and Windows will use the Edge-based WinRT webview where available (Windows 10 version 1809 October 2018 Update or later). On Windows, you’ll also need to enable the JUCE_USE_WINRT_WEBVIEW flag in juce_gui_extra.

On older platforms, the WebBrowserComponent will fall back to using the older webviews.


It’s now possible to run JUCE programs on Linux without requiring GUI libraries to be installed on the target machine. This has removed the x11, xinerama, xext, webkit2gtk, and gtk+-x11 runtime dependencies. The headers are still required to build JUCE projects, but at runtime the libraries are dynamically loaded and, if they aren’t present, JUCE will run headlessly. This also means that the Projucer can be run headlessly without requiring xvfb.


Building and hosting VST3 plug-ins is now supported on Linux!


This commit adds some missing functionality in the macOS CameraDevice since the switch to AVFoundation where getAvailableDevices() would always only return “default” for the default system camera device. This method will now return a full list of all available camera devices which can be selected and used.

This commit adds a HWNDComponent class for embedding non-JUCE HWNDs, bringing Windows in line with the other platforms.


@reuk has added the Android Oboe library files directly to the JUCE source so high performance JUCE audio apps on Android can be built straight out of the box.

We’ve also added a JUCE_USE_ANDROID_OBOE_STABILIZED_CALLBACK option to juce_audio_device to enable the use of the oboe::StabilizedCallback for stable audio performance on Android devices.

1 Like

do you know if on windows this will use edge chromium?

1 Like

It’s using WebViewControl under the hood, which I believe is EdgeHTML and not Edge Chromium.


VST3 CC Improvements

The VST3 wrapper has been taught to understand a wider variety of Vst::Event
types. In particular, it now understands the kLegacyMIDICCOutEvent type,
meaning that VST3 plugins can send and receive MIDI CC messages, as well as
channel-pressure, pitch-bend, program-change, quarter-frame, and poly-pressure
messages. It also fixes an issue where the kPolyPressureEvent was incorrectly
being converted to a channel pressure MIDI message. Now, kPolyPressureEvents
will be converted to polyphonic aftertouch MIDI messages, and channel pressure
changes can be communicated using the new kLegacyMIDICCOutEvent support.

You don’t need to do anything to take advantage of this change. VST3 plugins
built with JUCE 6 will simply be able to send and receive a broader variety of
juce::MidiMessage types from your plugin’s processBlock.

AudioPluginHost Improvements

The AudioPluginHost app now directly contains the audio plugin examples which
are also distributed with JUCE. Much as the DemoRunner makes it quick to find
out which JUCE widgets are available, the AudioPluginHost now acts as a showcase
for JUCE’s plugin-related functionality.

JUCE 6 also contains a new “MIDI Logger” example plugin, which is useful for
debugging plugin MIDI output.

IPP FFT Support

The JUCE FFT can now use the Intel Performance Primitives FFT functions
internally, giving developers a choice of IPP, MKL, FFTW, and Accelerate
FFT implementations. To use, simply install the IPP library, and then select
your desired kind of linking under the “Use IPP Library” option in the Projucer.

Parameter Attachment Ergonomics Improvements

The AudioProcessorValueTreeState::Attachment classes make it easy to connect GUI
controls to audio parameters. Improvements in JUCE 6 allow GUI/parameter
connections to be made without any use of the AudioProcessorValueTreeState

A new set of standalone ParameterAttachment classes are provided, including a
SliderParameterAttachment, ButtonParameterAttachment, and
ComboBoxParameterAttachment. These attachments can be constructed using
references to a RangedAudioParameter and a GUI control, and will keep the two
objects in sync for the duration of the attachment’s lifetime.

JUCE 6 also includes a generic ParameterAttachment class which can be used to
implement new attachment kinds for custom GUI controls like XY-pads and EQ


Lots of Projucer changes on the juce6 branch. We’ve removed analytics from the Projucer, removed the sending of JUCE app usage information, and removed the requirement to sign in to a myROLI account to use the Projucer:

We’ve also removed webviews from the sign in process and replaced it with a simple form so the Projucer has fewer dependencies and we will no longer have issues with older Windows versions using outdated IE engines causing script errors:

This commit also adds a notification tray which replaces many of the old popup windows.

The global VST3 path setting has been removed and projects will now always use the bundled VST3 SDK included in JUCE:

However if you really need to use a custom version of the VST3 SDK there is a JUCE_CUSTOM_VST3_SDK flag which can be set in juce_audio_processors which won’t add the internal VST3 SDK paths so you can add them to your project yourself:

And finally, we’ve added the full list of iOS orientation options to the Xcode exporter which was a feature that was requested a while ago:


I am very keen to try out the new DSP components - when will these be available for public review? Thanks

I’m excited for JUCE 6! The commit summaries are much appreciated. I’m new to the community and was initially disappointed that development is somewhat private (e.g. not via github PRs) but getting detailed context posted in the forums is great. Thanks!

Improvements in JUCE 6 allow GUI/parameter
connections to be made without any use of the AudioProcessorValueTreeState

I’m curious if the intention is mainly to provide a lightweight way to bind UI controls in demos/mini-projects, or if there’s Reasons one might want to keep parameters out of APVTS.

1 Like

I’m honestly really interestsed in this aswell. I already coded lockfree queues to communicate my parameters between main and audio threads but it’s less clean. I just took a brief look at ParameterAttachment code but will wait until the release to see if it’s worth switching to it.

1 Like

The biggest change in this area was to make the ‘generic’ ParameterAttachment class public, which in turn makes it easier to bind custom GUI widgets to parameters. Removing the dependency on the APVTS was just a nice side-effect, which may make code organisation more flexible. If you don’t want to use an APVTS for whatever reason, you don’t have to miss out on the useful attachment classes. Also, even if you do decide to use an APVTS, you no longer need your editor to know about the APVTS or your parameterIDs when creating attachments (as you can pass parameter references instead), which reduces unnecessary coupling.


Thanks for the clarification! I actually was initially going to ask “was this mainly a side effect of the refactor?” but thought it might come across as dismissive :slight_smile:

Even if you do decide to use an APVTS, you no longer need your editor to know about the APVTS or your parameterIDs when creating attachments (as you can pass parameter references instead), which reduces unnecessary coupling.

Ahh, I was trying to imagine a situation where one has an APVTS but purposefully doesn’t want to expose parameters to the host or something. Pretty interesting idea that the editor wouldn’t have to know the specific parameterIDs. I guess that implies one could “hydrate” a component with parameter references in a more programmatic way…