Jules, the creator and prime maintainer of JUCE, is indefatigable. I think maybe he's triplets, but nice triplets. He answers questions on the forum (http://www.juce.com/forum) at all hours and with extreme patience. There seems to be absolutely no difference between the way he treats casual users vs. enterprise customers on the forum.
JUCE can be used to develop audio plugins, synthesizer programs, etc., but is also a complete framework for GUI apps that have nothing to do with audio. It has canvas drawing, 3D support, and forms support.
There's a ton of documentation on the site and the source code is a dream to read. If you were creating an API for something you would be well served to see how Jules did it.
I rank JUCE with web2py as one of the two most comprehensive, ridiculously underrated open source products I've encountered.
Edit: As far as existing software is concerned, I'm on Linux and I'm not interested in moving to Windows or OS X. I realize software for Linux in this domain is somewhat limited.
By the way, does anyone know of a good comparison of OSC and ØMQ (ZMQ)? I'm curious about when to use which of the two in terms of latency and ease of use, apart from that OSC is built for audio while ØMQ appears to be more general purpose.
There's a set of problems that tend to go together when you're doing audio tech development: We have to build apps/plugins that run on many platforms and plugin APIs (so managing many different compiler projects for the same codebase is really helpful). We always tend to have complicated and custom GUIs (hence all the GUI framework stuff). And there's a whole set of other commonly needed library code that we provide.
Re: the live-coding stuff, initially we've found it really useful for GUI design - isolating individual GUI classes and nudging their code around to get the behaviour right, rather than having to repeat the tedious edit->compile->run->navigate cycle. But it has a lot more potential uses that we're just starting to explore, and hopefully as it becomes more solid, our users will think of even more things it can do.
Then for anything that is an arbitrary data transformation it could be done live and in isolation.
The interface is so clean and fast I really want to start using it. It really seems like a great way to try out ideas quickly but still end up with native executable. There isn't even an install to go through which I actually really like.
So it would take a really strong incentive for someone to create and maintain a full-featured binding to another language.
But TBH I've never quite seen the point of binding scripts to C++ classes in general.. C++ is already a great way to write that code, why have a messy layer in the middle!
The place where I'd have thought it makes sense is for custom APIs, e.g. in Tracktion we let the users write javascript to control the app in response to keyboard shortcuts, but for that we have our own API that they can call. Never quite understood the use-case for more general library bindings to generic GUI classes, but I guess people have their reasons!