JUCE is a very, very well-designed cross platform framework that was used very successfully in the development of Tracktion, a competitor with programs like ProTools and Garageband. The API is C++ based but carefully designed to shield you from the weirdness of C++; if you needed to create a cross platform app and learn C++ at the same time this would be the gentlest possible introduction.

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.

Max/MSP, one of the more popular visual programming languages out there, is also written using JUCE.

https://cycling74.com/forums/topic.php?id=11656

Does it use any native controls, so that you can build an app that looks and feels native? Could you build, say, something like the Spotify desktop app with it?

I'm interested in writing a fairly bare-bones, standalone application for note sequencing, patch selection, and controlling the master clock of external MIDI synths and drum machines. Is this a suitable framework, or is there something else that might be more appropriate? I feel like the current DAW offerings are A) too complex/big for my needs, and B) focus a lot on MIDI in and not very much on MIDI out. That said, I'm really new to this so I'd appreciate any suggestions on existing software I might have missed.

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.

JUCE is perfectly aligned with your requirements.

Seq24 may be what you're looking for. It's a sequencer, and doesn't try to be anything else.

It's great to see that the OSC module is being added to JUCE! In our lab we are working on adding OSC support to OpenEphys (an electrophysiology software that uses JUCE). Currently we need to bundle or statically link oscpack on Mac and Windows, but with OSC support built into JUCE we won't have to deal with that anymore.

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.

This looks interesting but I'm having a hard time figuring out which problem it solves, specifically. It seems to do lots of things: GUI, Audio, Project Management - but I already know of tons of ways to do these things. Can somebody explain who would need this and for what? Maybe I'm just not the target audience, I don't mean to be disrespectful.

(Author here)

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.

julesrms, Interested in the live coding, but can't seem to find any detailed info on your site. How does your live coding compare to, say, Cling ( https://root.cern.ch/cling ) ?

Cling is more of a REPL, whereas ours is more of an IDE-like environment. And rather than just calling a function or expression, the Projucer invokes code by instantiating one of your GUI component classes

A workflow I think would be extremely useful would be to take serialized data, live program some sort of data transformation, then visualize the result (and maybe the initial data too)

Then for anything that is an arbitrary data transformation it could be done live and in isolation.

Yeah, that's the kind of thing it can do. We've got demos of live-coding audio algorithms, for example, which is the same kind of process.

i used tracktion many years ago and remember reading about the underlying juce framework, but i was dissuaded by the lack of bindings to other languages. i know real-time audio is inherently low-level, but are there any plans to expose the api to other languages to make it easier to experiment with?

This has been partly done several times with Lua (one by myself). One problem is that JUCE is not a C framework, it relies heavily on C++ features (notably, using it means deriving lots of parent classes and interfaces). This makes language bindings a bit more tedious, especially if you want your binding to keep up with JUCE's non-stop development.

So it would take a really strong incentive for someone to create and maintain a full-featured binding to another language.

The smart way to generate bindings nowadays would probably be to use Clang to get an AST and auto-generate the wrapper code.

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!

i kinda figured the gui stuff would be impractical, but what i was more interested in was a low friction way to play with midi / audio buffers. i haven't worked with c / c++ since college (too busy paying the bills in a managed shop), but i guess this is as good an excuse as any to get back into it. the fact it comes with its own ide / tooling is nice because learning an entirely new workflow / tool-chain is a barrier in itself.

A large number of users for this framework use it for audio plugin development. It supports building VST, AU and some other formats and provides a nice consistent way to build UI for your plug ins that is otherwise not readily available. If I remember correctly that was the original purpose of this framework and has been expanded to include other areas.

This is what they should write on the homepage, thanks!

I just downloaded this and tried it out. Does it not compile at all on windows?

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.

We're actually waiting for a few gremlins in Clang/LLVM's Windows support to get straightened out before it can successfully compile on Windows. Fingers crossed we should be able to release a working version in the next couple of weeks..