Juce 5 Features


#1

So I got the Email, but it seemed rather vague on the new Juce 5 features. Can anyone share?


#2

I guess the JUCE team want the licence debate out the way first before the ‘reveal’ on the 27th.

Personally I’ll be interested to see if the new c++ 11/14 stuff could provide an alternative to all the AudioParameterXYZ pointers lying around in my Processor classes, they make me twitchy. :grimacing:

Dave


#3

I’d be happy with twice as much documentation of the existing features :slight_smile:


#4

What do you think needs more/better documenting? One of the biggest (if not the biggest) draws of JUCE for me has always been the exceptionally readable class interfaces with the documentation supplementing them without being overly verbose.


#5

I thought a lot of these new things in Juce 5 are available at the GitHub develop branch. That branch says it is governed by the Juce 5 license…


#6

+1

The self-documenting code to me is really what sells it.


#7

So, what is actually new on the develop branch then? The ChangeList.txt file seems to be dated, last changed on Jan 26.

I found out that VS2010 and VS2012 support is gonezos the hard way. This stuff outta be outlined in bold…

What I’d like to know is what sells JUCE 5; what major advancements have come into play that really make it worthwhile? As per 4.x, Projucer’s here, looks like there are new WinRT MIDI things, and Roli Blocks support, and a wad of bug fixes. So, why JUCE 5?


#8

I would hope that they announce the DSP classes are going to be included in JUCE 5 next week - otherwise it does seem like a small upgrade.

Cheers,

Rail


#9

Exactly! I’m curious to see what is warranted in the new version 5.0. Version 4.0 added AUv3, which to me, was well worth it. If each upgrade yields an additional $999 a year, it would seem that each upgrade will be somewhat “revolutionary.”

What I’m hoping for personally is some much needed GUI/GPL stuff. Stuff that looks as cool as Apple stuff with animations to make the apps look really professional. At the same time, a much needed overhaul of the OpenGL integration with very low CPU for image resizing etc…


#10

Don’t forget finishing the Direct2D renderer on Windows so we don’t have to deal with the horrifically slow GUI performance ALL JUCE apps have under Windows with the software renderer…

Or just go all in with next-generation APIs by building LowLevelRenderingContext implementations for Metal and Vulkan, which don’t require any sort of multi-thread/lock/blah blah blah insanity to do off-thread graphics command buffering.

I feel like a kid at Christmas hoping for a DSP module or improved graphics come April 27th, but even if there’s no mega announcements yet I think the major C++11/14 refactoring/cleanups are worth the cost of admission alone.


#11

My main gripe with this is how much of a change for the better is it, really? Code design or tighter architecture? Performance? Has anybody here done performance measurements with C++11/14/17 code vs Ye Olde C++, particular in a JUCE context?

I’m genuinely curious to see the advantages, and objectively the disadvantages. I’ve watched a slew of videos, read a boat load of documents and whatnot, but very little is persuading me to say “All of this as a whole makes C++ so much better. Why didn’t they just do it this way from the get go?”. Over time I’ve changed my philosophy to keeping it simple all around, basically C with classes, and with all of this cheerleading I’m skeptical.

Obviously some things have made C++ simpler (range-based for comes to mind), and some new features like move semantics are great though a little bit complex…


#12

There are certainly C++ complications JUCE has avoided (and continues to avoid) like exceptions, variadic templates, complex metaprogramming, and abusing auto (though some of the recent commits have me nervous about that one). The JUCE team has definitely been cautious and not overzealous about adopting C++11 into the code base.

I think the C++11/14 additions are definitely more about usability and readability than performance - it’s definitely harder to wrap your head around writing high-performance code when using abstract language constructs like lambdas, variadic templates, etc. Under the hood there’s still plenty of traditional C++ going on, in fact most of the interfaces I’ve looked at the guts of which pass lambda arguments just use traditional function pointers in the background.

The biggest (and most useful) embraces of the additions appear to come in the form of the override and noexcept specifiers (and their ilk), which just exist to clarify intent without affecting performance. I think those are the most useful (even though they’ve been adopted for a while now) while being able to pass lambda functions as direct arguments is just a huge convenience boost.


#13

Self-document code is great about 50% of the time. But sometimes it’d be nice to have the flexbox example in the documentation rather than just “To use this class, set its parameters appropriately (you can search online for more help on exactly how the FlexBox protocol works!)”

Or information on the thread safety of various bits and pieces.

And other stuff that’s more than an 15 minutes reading the source to work out otherwise :wink:


#14

What did that email say? Looks like some of us didn’t get it or missed it somehow


#15

See the 2nd post in this thread -


#16

Yes. I’m curious to hear about the new “user interfaces” and hopefully any ProJucer component enhancements.