Announcing JUCE 6

OK, I think I know what’s going on here. I suspect it’s this:

The legal wording in the JUCE 5 EULA means that we cannot upgrade people’s subscriptions automatically (but this is fixed for JUCE 6).

I’m in Canada, am I supposed to be paying VAT? If it’s null VAT, why does it increase the price?

Monthly amount thereafter

$50.00 (including null VAT at 25%)

No, that’s not right. We’ll fix.

Update: should be fixed now, just need to wait 10 mins for the shop to come back online

OK t0m, thanks for the reply. How do I fix this?
edit OK I’ve gone back to 5 which is available with
git checkout 3050ab7060
… which I presume is the last 5.

Yep, 3050ab70 is the final JUCE 5 commit - using the code past that point in closed-source commercial applications will require a JUCE 6 licence. Disabling the splash screen option in the JUCE 6 Projucer will also require a JUCE 6 licence but you are no longer required to sign in to use it, and no analytics will be collected either in the Projucer or JUCE apps built with 6.

The message you are seeing it to flag that the splash screen is disabled without a compatible licence type found in your account, and saving and exporting the project will be disabled. To re-enable, you can either enable the splash screen setting or sign in with an account that has a JUCE 6 Indie or Pro licence, or is using the GPL.


Thanks I think I understand, so how do I become a 6 user for my next project?

You can upgrade your subscription to JUCE 6 in your JUCE account dashboard:

Nice one t0m. Thanks. I presume I can still load and build 5 projects with the 6 licence?

Yes, that’s correct.

1 Like

Would you mind tagging that final JUCE 5 commit somehow, so that it’s easier to find it in Git clients?


The final JUCE 5 commit is already starting to look buried way down in Git clients… any chance for its tagging to happen?

Why can’t 5 be a separate branch? You don’t need a ‘develop’ and ‘master’ version of 5.

We don’t want to complicate the version history or our branching strategy unduly. I understand that if you are already familiar with git then you won’t see this addition as particularly harmful, but we see a lot of people starting out with version control being confused with what we have already.

The last JUCE 5 commit can be located fairly easily by going to the commit immediately preceding the tagged 6.0.0 release.

Isn’t the idea behind ‘branch’ to have different versions? It’s much easier to select a branch than it is to find an individual commit.
I get it though, you want as many people to invest in 6 as possible.

The command to get latest JUCE 5 is git checkout 6.0.0^, easy enough imho

Correction: that commit already seems to include the 6.0.0 version number in the files, so my comment was incorrect

1 Like

But does that mean they can’t update 5 now? Or can bug fixes be slotted in somehow?

1 Like

I would imagine that “not be updated to remain compatible with the latest versions of operating systems or other libraries and frameworks” also refers to DAWs etc.

1 Like

the release notes state:

  • Better handling of VST3 MIDI CC messages

What does that mean exactly?

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.


Ok, thanks!

Does JUCE do all this automatically when I attache controller events to the midi buffer in the ProcessBlock or do I have to take care of these things myself?