[djfm]

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.

[julesrms]

(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.

[choppaface]

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 ) ?

[julesrms]

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

[CyberDildonics]

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.

[julesrms]

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.

[mrblah]

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?

[pierrec]

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.

[julesrms]

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!

[mrblah]

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.

[S_A_P]

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.

[djfm]

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