Juce: An extensive, mature, cross-platform C++ toolkit

http://www.juce.com/

by wslh • 13 years ago

92 85 13 years ago

shaggyfrog• 13 years ago

A former client of mine considered Juce for a cross-platform project several years ago. It seems to be popular in the the audio programming segment. The biggest drawback is the lack of native look-and-feel; Juce apps don't "feel" native, and that's usually enough to keep it an also-ran for most use cases.

I don't really see the big advantage for these cross-plaform GUI frameworks, anyway. Trying to force a standard interface across diverse platforms means coming up with odd idioms or patterns to achieve a kind of artificial homogeneity. Better to concentrate effort on making the business logic cross-platform, IMO.

vinkelhake• 13 years ago

From the screenshots it looks like this toolkit is meant to be used in applications where a non-standard interface is the standard. For some reason this seems to be the case in a lot of audio applications.

logn• 13 years ago

Audio apps tend to need to have special UIs and widgets which aren't typical needs for most apps. You need special sliders, drawing tools, and color schemes for live performance that aren't baked into many widget toolkits. Even if they are, you're dealing on such microscopic levels of detail on these UIs that you really do want them to be the same pixel-for-pixel on any machine. And if you're selling a cross-platform audio plugin to musicians for a couple hundred dollars for the last 5 years, it's nice to totally remove OS-specific UI weirdness from the equation.

Here's an example UI showing my point (and the app Juce was spun out of) http://www.tracktion.com/

malkia5• 13 years ago

That's true, but if you are plugin developer and your platform (audio, 3d, etc.) is already cross platform (linux, osx, windows) then getting the same look&feel might be your priority - e.g. if there are knobs, switches - especially found in audio plugins - it'll be very good to have the same interface (few exceptions) everywhere.

I also understand the need to use native, or look-like native widgets where possible, but juce started (from what I know) as project isolated from Tracktion which ran on osx, linux, windows, etc - http://www.tracktion.com/

FigBug3• 13 years ago

I was the lead Tracktion developer for a while, Jules sold Tracktion to Mackie where I worked on it. Then Mackie lost interest in it and eventually sold it back. It was my first experience with Juce comuing from an MFC/Win32 background. It's a very nice library with a clean, consistent interface.

A few of the downsides have already been mentioned, but there was one big upside in that there was an amalgamated version of the library that put the entire library into one cpp file and one header file. It made building and distributing applications so simple compared to a lot of other cross platform libraries. (Qt/wxWidgets) I used it for a lot of command line utilities (I believe the core of the library is BSD rather than GPL) Makefiles were as simple as building two cpp files. I really like C++, but getting it to build with dependencies on a bunch of platforms is usually such a pain in the ass.

I used Juce for one more major application after Tracktion, EAW Resolution (LOUD Speaker modeling), but after the first version was released the licensing model of Qt changed to LGPL and it was ported to Qt. Qt has a lot more support behind it. And while Qt isn't perfectly native, it's a lot closer. The projects I work on just don't have the budget to do separate native versions for each platform. It's usually just me, or maybe one other developer.

wslh3• 13 years ago

Juce apps don't "feel" native, and that's usually enough to keep it an also-ran for most use cases.

I experience the reverse, customers are asking us all the time for adding non-standard custom draw GUIs. I found that doing non standard UIs we can also charge more for the risks involved.

JabavuAdams• 13 years ago

In-house or multimedia tool development.

zokier4• 13 years ago

Nativity in UIs is over-rated imho. Tons of apps I'm regularly using do not have native UIs and still fare quite well. Heck, I'm not even sure what the native toolkit for my platform (Windows 7) would be. I guess WPF would be the closest thing?

Most notorious example would be Microsoft Office which afaik never has used native widgets, being always one step ahead of Windows UI design. Other examples out of my head are the whole Adobe suite (which is arguably a mess UI wise), both Firefox and Chrome, Spotify, Steam, Blender. iirc the Open/LibreOffice widgets are custom too. And of course GIMP has its own toolkit, even if it is spread bit beyond GIMP itself.

hyperbovine2• 13 years ago

Most notorious example would be Microsoft Office which afaik never has used native widgets, being always one step ahead of Windows UI design.

And yet when Office switched to the ribbons interface, all hell broke loose. The moral being, people hate having to learn a new UI. Consistency matters.

spacelizard• 13 years ago

Actually the last few iterations of VS and Office skinning have gotten added into MFC and can be enabled pretty easily for any app. The Ribbon UI is also fully available in MFC and VS. Just no one uses any of this stuff for obvious reasons.

http://msdn.microsoft.com/en-us/library/vstudio/cc137831.asp...

http://msdn.microsoft.com/en-us/library/ee354408.aspx

Spotify actually uses Qt but with a custom stylesheet that makes it look more like iTunes. I have no idea why they did this, I think it makes it look terrible and clunky. Read this for more info:

http://blog.qt.digia.com/blog/2007/11/27/theming-qt-for-fun-...

julesrms11• 13 years ago

The main reason I never added a native-widget implementation to juce is actually just lack of demand! It was very rarely requested, so was never a priority.

That might just reflect the kind of crowd who use juce, but I do think that native widgets are getting less important these days, as people become more and more accustomed to website UIs where every site has its own style.

Also, back when I started all this, semi-transparent HWND child windows weren't possible on Windows 2000/XP, and early OSX versions also struggled with this. The stuff I was building at the time needed a lot of semi-transparent graphics, so the best approach was simply to render the entire GUI in software and not be limited to what the OS offers. (And for many situations that still makes sense).

nicholassmith2• 13 years ago

Looks interesting, I come from a Qt background so cross-platform toolkits always have a bit of interest for me. It does seem like it's definitely for people building highly customised interfaces, rather than looking for OS-based look and feel but there's some nice bits. I think I'll give it a whirl when I've got time for a side project.

Keyframe2• 13 years ago

My first thought, as well, was why should I use JUCE over Qt. Especially considering license. I'll have to look more carefully through code.

malkia5• 13 years ago

We use Qt at work for one of the big projects, and we are very happy. That to be said, juce is small, embeddable (your executable can be around ~600kb on windows), and while you can statically link to Qt it's still bigger, and some things don't work right (plugins).

wslh3• 13 years ago

Probably the audio support in Juce is better than in QT?

nicholassmith2• 13 years ago

Looking at it quickly, you should use JUCE over Qt if you're building a custom UI from scratch and you want a lot of multimedia help, you should use Qt if you're building a more traditional desktop application.

Bill_Dimm• 13 years ago

According to the About JUCE page the license is GPL, so you need a commercial license if you want to use it in a non-GPL project. The pricing doesn't look too bad if the library is solid (£399 for a single project, £699 for unlimited).

They really need a lighter color for the text on their website -- tough to read.

jbrooksuk3• 13 years ago

This makes me wish that the developer of Sublime Text would release his UI toolkit. It's completely cross platform too.

wbond2• 13 years ago

I think one of the reasons Jon manages to pull it off so well is how basic it is. He has a 100% custom sidebar (very basic), but other than that he is using native menu controls and standard dialogs. Obviously the editor pane is the big custom component.

jbrooksuk3• 13 years ago

That's a good point. I think one of the reasons Sublime works so well is because the interaction is minimal and unobtrusive. You don't realise how simple the controls are - as you said; standard dialogs etc.

kbd• 13 years ago

Plus, there's not even a configuration/preferences screen. It's all text. So, no gui widgets needed.

qznc• 13 years ago

Sounds like Scintilla http://www.scintilla.org/

hemmer• 13 years ago

I've been using JUCE for a couple of years for VST development. I've found it to be a very well put together library for audio work (diving straight into Steinberg's SDK is pretty daunting for someone new to audio like myself), and a lot just works out of the box.

There is strong leadership from Jules on the direction of the library which is generally a very good thing, though it does mean that sometimes there isn't much room to budge on controversial issues. Font rendering is one aspect that several have battled with for a while, I've struggled to get good crisp smaller fonts without resorting to using freetype. Jules argument seems to be that small fonts shouldn't be used period, therefore the library wont render them well (I think there are technical as well as philosophical reasons for this, particularly on OSX). While I agree they should generally be avoided, there are certain situations where this isn't the case (reproducing an exiting GUI for a client, fitting non-critical text in when screen real estate is at a premium etc).

Overall I would certainly recommend for anyone starting out in audio development, but be prepared to fiddle around with fonts; I'm not so familiar with the non-audio parts of the library.

wbond2• 13 years ago

I realize this may be slightly off-topic, but is there something like this that focuses on building cross-platform apps that have native UIs?

I've obviously seen wxWidgets, but I'd even be interested in commercial offerings.

eropple• 13 years ago

They exist, but none of them I've run into are particularly good. I'd say that Qt is probably the least-bad, but it feels very "wrong" on OS X and only somewhat better on Windows.

asveikau4• 13 years ago

Kind of weird how he wrote his own string class, as well as rewriting some other perfectly good standard library stuff.

His version of scoped_ptr seems to fake rvalue references without actually using rvalue references, but does so in a copy constructor. IMO this is a bit bonkers. If you're not going to use rvalue references I think move semantics is better done from a method, not a copy constructor.

Still looks like a handy library for wrapping things that are otherwise not portable.

Edit: I was mainly basing that comment from looking at juice_core... There's a crapton of other stuff too. Impressive for a one-person work.

stinos• 13 years ago

Kind of weird how he wrote his own string class, as well as rewriting some other perfectly good standard library stuff.

not that weird: Qt and others do it as well. Not sure why though, maybe because at the time they started there was a lack of a decent std::string implementation on all platforms?

asveikau4• 13 years ago

Qt does it because the library predates common availability of std::string across multiple compilers. It's been a while since I looked but there is a lot of funky stuff in Qt that would look saner if they had the benefit of starting with a recent standard.

zokier4• 13 years ago

std::string is very low-level interface, and has eg. very little to no provisions for Unicode.

FigBug3• 13 years ago

He started working on it 2001/2002, at that time, C++ implementations of the standard library were poor and inconsistent across compilers. There is a reason that pretty much every library from that era redid all the basic classes - Qt, MFC, etc. When I learnt C++ it didn't have std::string.

asveikau4• 13 years ago

Qt and MFC are quite a bit older than 2001/2002. It makes sense to avoid std::string in the early or mid 90s. By 2001, though...

julesrms11• 13 years ago

Ok, the reasons are/were: 1. Back in 2001-ish, Java was cool, and I was copying the java string class. 2. I wanted more functionality than std::string offers. Yes, yes, I know all the arguments about keeping the class simple and using external methods for adding functionality, and I generally agree with that philosophy, but having used both juce::String and std::string, in practice the juce design just seemed to result in cleaner code. 3. I wanted it to be able to easily cast to utf-16 or 32, and std::string was a bit clunky for that. 4. It's a long time ago, but I vaguely remember std::string having performance issues on some platforms.. Can't remember the details, but there were definitely problems that made it perform differently on different compilers.

If I was designing a string class today with hindsight, I'd probably still go for the overall design of juce::String, maybe tweaking some of the methods a bit, but I might make it wrap a std::string so that they can be interchanged efficiently.

corysama• 13 years ago

The editor in Juce apparently features C++ live-editing/hot-reloading http://youtu.be/imkVkRg-geI

julesrms11• 13 years ago

Yes, but sadly still not yet released, due to me having absolutely no time to work on it :(

(Anyone who finds the Projucer project interesting and who might be interested in throwing some resources at it, please get in touch!)

fbomb• 13 years ago

All it needs is a spellchecker ;-)

yeureka• 13 years ago

I looked at Juce a while a go when researching native GUI libraries and ended up choosing QT, but seeing that resolume uses Juce I might have another look at it.

shadowmint• 13 years ago

Oddly, I love everything about this except the Introjuicer, which basically Yet Another XML Based Build Tool.

Quote from the author:

    When I first decided to build the introjucer, my first
    approach was also to use cmake, but on investigating, 
    it really was far simpler to just cut out the 
    middle-man.

Dang~

Looks like I won't be using it after all; nothing I love less than learning new build systems.

lukaszdk• 13 years ago

I've used JUCE professionally for almost 2 years now and I find the introjucer to be a very poor substitute for CMake.

It is all GUI based and hardwired to a single XML file with predefined settings, so there just is not a lot of flexibility for setting up more complex projects nor sharing settings across projects.

Even the things that introjucer does support, it does not always do well, like icon support or keeping up with the latest iOS changes to Xcode for instance.

The general problem with JUCE is that is just a too ambitious project for one man and feels like a "well executed hobby" library instead of a "professional production" library. There are a lot of inconsistencies and bugs that you quickly run into when you dig deep enough into the library.

Issues are fixed and introduced on a daily basis, you have to be very careful when updating the latest "release" (which seem quite random) as your existing code could break.

https://github.com/julianstorer/JUCE/commits/master

That being said, I think the price for a commercial license of JUCE is a steal if you are working with C++ audio/DSP programming and it will save you a lot of time up front.

You just have to keep in mind that you will probably need to invest time in patching/extending JUCE due to the fact that only one guy is maintaining it and he only has so much time to work on it every day.

julesrms11• 13 years ago

Well, I designed it to make my own life easier, and if it's useful to other people, then great! Personally I couldn't live without it now, it saves me a huge amount of time in managing projects, but obviously people's mileage will vary..

But something thing about the design of the codebase is that it doesn't need a fancy build system - you can include everything in a project by just compiling a handful of cpps that wrap up all the code into module-sized chunks, so if you do want to use juce in some other tool, it should be very easy to do.

fxtentacle2• 13 years ago

yeah, i dislike the introjucer too. however, you usually need it precisely once to set up the initial projects for each platform. after that, i never touch the introjucer again but manage my projects by hand.

foxhill3• 13 years ago

in his defence, cmake is awful. it is my least favourite of all the build systems.

iainduncan• 13 years ago

I looked into this for an audio app, and it looked really cool. Then I contacted him to find out what contingencies were in place because of the truck number of 1 (!!). I asked him if he had any business partner, or perhaps a dead man's agreement in place in the license by which if the company folded or he left it would revert to open source. Not only does he not, but he was a jerk about it, completely dismissive of it as a valid concern. No way would I put years of work into a project on a platform that might become stagnant because of his lack of foresight or understanding there. So I just used QT and other audio only toolkits. Pity, it's really neat looking.

eliasmacpherson2• 13 years ago

Correct me if I'm wrong - but there was commercial and GPL licences, are the GPL licences gone?

julesrms11• 13 years ago

No.. it's still GPL.

julesrms11• 13 years ago

..actually, I should mention that although most of the library is still GPL, the core module is now under a permissive ISC license. So if you're doing non-GUI or audio stuff, you can use many of the core classes for free.

julesrms11• 13 years ago

Well, that's the beauty of open-source... I try to be hit as few trucks as possible, but it certainly wouldn't mean the end of the project, just perhaps a slight drop in code-quality :)

I remember you getting in touch and asking about this because I think you're the only person who ever asked me about the truck-number. Slightly surprising, really - I've sold licenses to all kinds of huge mega-corporations who I would have expected to worry about such things, but apparently not. Just you!

pekk• 13 years ago

How did "toolkit" come to mean "GUI library"?

foxhill3• 13 years ago

it does a lot more than cross-platform GUI.

it says what it can be used to do on the front page.

eschaton• 13 years ago

The Lisa had the Application Toolkit, which was a shared library written in Clascal (predecessor to Object Pascal) that had all of the basic behaviors of an application.

Then the Macintosh had its function library, called the Toolbox. That's where a great many people heard the term. (The Mac didn't have a framework, though it did get MacApp later - which was similar in design to the Application Toolkit and originally written in Object Pascal.)

fxtentacle2• 13 years ago

been using it for years, its brilliant :)

I'm developing professional audio and 3d tools. In these areas, people expect a GUI that ignores native styles and looks identical cross-platform. That is precisely where juce excels.

skrebbel3• 13 years ago

I like how all the examples look like VST plugins. Seems that the horror that is VST GUI paid off, because it triggered someone to do better! (note: that's a completely uninformed guess)

I didn't know about this though, and will definitely consider it if I'm ever bound to C++ again.

I especially like how iOS and Android are targets. Easy to code, highly customizable, fast/native, cross platform mobile apps? Yes please! Sure, Qt can do all this too, but I suspect that many app designs might fit the "audio plugin" UI design attitude better. Especially if you have a designer who likes to .psd every single control.

foxhill3• 13 years ago

if i never have to use VST GUI again, that wont be long enough.

honestly i think steinberg were pushing for using native widgets. i'm confused then, as to why the native UI system looks just.. terrible.

sambecket• 13 years ago

Juce is an incredible framework, jules is also a great guy, he implements stuff daily that the community requests. It makes creating C++ stuff even fun !

samograd3• 13 years ago

I think I see the insides of a Lisp hiding inside ;-)

   http://www.juce.com/documentation/tutorials/valuetree-class

samograd3• 13 years ago

@julesrms: I'm looking through the docs and can't find the answer: Do the drawing functions support anti-aliased 2d primitives (lines, circles, etc)? I'm looking for a C++ 'Canvas' type object that's requires very little code setup; just let me open a window and give me an anti-aliased drawing surface. Could JUCE help me with that?

julesrms11• 13 years ago

Yep, tons of anti-aliased 2D stuff, using either a 100% software renderer, CoreGraphics, or an openGL shader based renderer.

samograd3• 13 years ago

Thanks, I'll take a closer look then. How do you think it would handle with rendering massive images for canvas printing, like, say 3'x2'@300dpi or bigger pixels?

julesrms11• 13 years ago

Thanks for all the sudden attention, HN readers - my website's just about surviving the onslaught! Hope some of you discover JUCE from reading this!

I'd just like to say that if anyone tries the demo app and finds it a bit tired and old-fashioned, that's because it is! We're in the middle of writing a new demo at the moment that'll show off a lot more of the library's cool features in a slick way, but it won't be ready for a couple of weeks. (Ideally I'd have waited until that was ready before getting HN'ed, but am still grateful for the hits!)

blt• 13 years ago

Cool to see you here Jules. I used Tracktion from around 2003-2008 and loved it. Always thought the UI was nice and I was excited when I found out about Juce. Whenever I get around to learning some DSP I'll use it to make plugins :)

julesrms11• 13 years ago

Thanks! Actually, one of my big tasks over the next few months will be to redesign Tracktion's UI and try to make it look at bit more contemporary. Quite an interesting challenge!

seabrookmx• 13 years ago

I worked at an audio company previously, and one of my main jobs was porting a large acoustic simulation suite from Juce to Qt (EAW Resolution).

Unless you really need the audio specific features that Juce includes (we didn't as we did everything in-house) there's really no point to using it.

Qt has a bigger community, more extensive (and IMO more well thought out) libraries, and as has already been mentioned, a native look and feel that can't be beat. Not to mention, Qt is completely free for personal and commercial use.

The only popular commercial app I know of that is using Juce is Smaart by rational acoustics. They used MFC before that if I recall, so obviously the cross-platform capabilities are a huge bonus. I still wondered why they didn't move to Qt like us though.

p0nce• 13 years ago

Juce is great especially for audio plugin developers, an alternative in this area is WDL-ol. https://github.com/olilarkin/wdl-ol

codeboost• 13 years ago

I've been using JUCE for various project for about 5 years. I really enjoy coding with it, once you understand the naming convention (which is different from everything I've used before), it's quite intuitive. If you use the API in a wrong way, it will assert somewhere inside the library, and the assert has a nice comment above it explaining what you did wrong.

The main benefit for me is the size of the executables - no other cross-platform GUI toolkit that I've used before can end up with such tiny executable files.

QT might be more powerful, but it's HUGE and that is a problem for most of the apps that I develop.

So great work Jules and do give it a try!

Juce: An extensive, mature, cross-platform C++ toolkit

Related Stories