Announcing JUCE 6

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?