I’ve been reading about JUCE, and I wanted to share some thoughts. This is NOT a thread on whether it should have been used in MAX over some other solution – I don’t know enough about either to have an opinion. But MAX led me to JUCE, which looks very intriguing. I am wondering what other audio application developers thought about it.

I think of QT as a large-scale effort to produce an outstanding cross-platform widget set (which it is, and more). I used for a large project, and it performed flawlessly. (I can’t get on board the GTK train because it’s not formally object-oriented. GTK obviously works very well, though, and it’s friendly to debug.)

JUCE is written by one guy (Julian Storer). And he only wrote it to support another program he was writing (Tracktion). Skepticism rising…

…but maybe that just means the code’s architecture is well focused (and that he never sleeps). There appear to be several unique features of JUCE. Architectually, Julian makes (everyone’s favourite rusty chainsaw) multiple inheritance a primary component of his object model. From my perspective, this has the possibility to reduce development time and increase code readability. For someone like me who usually codes alone, that’s very attractive.

The JUCE library is not as "feature-complete" as some others, but it appears to offer a strong feature set. Multithreading is supported (in some fashion), as well as fancy graphics stuff like OpenGL and transforms. There’s stuff that plugs into open standards such as SVG and XML. Most importantly, there is a ton of audio stuff built right in. I don’t know how well these functions overlap other libraries that are required in a given app, though.

Another cool thing is that the executable looks identical regardless of platform (WIN32, OSX, GNU/Linux). You can even have it all in one code tree. In that respect, JUCE looks looks like one of the closer frameworks for write-once, run-anywhere use.

Has anyone written anything in JUCE? If so, what has your experience been?

Bill