Curious about JUCE


#1

Hi everyone!

I’ve been looking for the past week into JUCE for some VST plugin programming. So far I have mostly liked it and I will probably release a couple of VST plugins open source (as per the GPL license terms) in the nearish future. Doing VST plugins however isn’t my dream job when programming, so…

What I’d like to get some insight into is how is JUCE for more complicated audio applications development? I understand of course there are NDA’s etc
involved with commercial companies that might be using JUCE for products currently in development and so on…But on a more general level, what would I be expecting to see if using JUCE for a full blown standalone audio application? It all seemed fine so long I had not read Jules’s comment here on the forum that Tracktion does not incorporate any/much of the JUCE code for it’s audio side.

So, my concern is, is the JUCE audio stuff robust and comprehensive enough and known to work well for audio applications development? Or would it be likely there will be lots of reinventing of the wheel/monkey work involved to get things running? If the case is the latter, it looks like I might be better off just using Qt, libsndfile and PortAudio as I already know those pretty well and they would be cost free to use and allow me to keep my source code closed. (A DAW-type app is “slightly” more complicated and “valuable” in terms of the source code it contains than some simple VST-plugins…) The things that interest me in JUCE for the audio engine type of stuff is the audioprocessors graph, threads that read-ahead audio sources, the audio image thumbnails classes etc…Those are somewhat “bitchy” to implement from scratch, and I’d be facing exactly that without JUCE. But I have no idea how those really work in practice, as it isn’t clear what already existing products might be using those etc.

I’d appreciate any insights anyone might be able to give me.

(If anyone wonders “Why doesn’t he just try the JUCE stuff out and see for himself how it all works?” : I have already wasted countless weeks trying out different approaches/solutions, and not really feeling like starting again blindly from scratch with a completely new programming toolkit and all that…)


#2

Hi!

It rocks!

Go for it! I’m building one and I’m absolutely happy with choosing juce, instead of struggling with multiple messed up libraries.


#3

I’m developing a full blown live performance tool using Juce and so far, it seems completely capable. In particular, Jules’ handling of audio devices is the most comprehensive I’ve seen. I especially like that I can pick up the channel names, that Juce supports DirectSound, ASIO, WASAPI, Mac, and Linux, and also that there is already a widget for producing a dialog to configure the audio source.


#4

Ok, thanks for the answers so far. But I have not yet read anything down to the details level…(There was even a removed/censored reply at one point???)

I’d especially like to know about all downsides what I should expect when delving into JUCE. The stuff I’ve used so far for producing my pretty humble bit crushing plugin doesn’t really touch some of the more complicated points about audio development…


#5

I can’t think of any real downside in the audio area from my experience so far. I haven’t used the AudioProcessorGraph, but all other audio classes and interfaces are very well designed. I am only working on a plugin, but one that that touches some areas you’d need for an audio stand-alone application (file handling, timeline stuff, edit operations, copy&paste, drag&Drop, sqlite/database stuff). The nice thing about juce’s classes is that everything feels very consistent throughout all these areas.

One think to consider for a standalone application is that the “standard” widgets ( like menus, dialogs, toolbars etc.) won’t match the operating system’s look and feel. See the juce demo to see how those widgets look by default. The good thing is that pretty much every aspect of their looks is exchangeable. If it isn’t, you’ll have to roll your own component, but that’s one of the areas were juce really rocks. The graphics/2d-geometry classes contain everything you’ll need, and allow you to do fancy stuff with very clean code, and the eventing works as expected even with lots of nested components.

So if your UI contains lots of specially designed widgets anyway, I totally recommend developping it in juce. If you want it to blend in with other OSX/Windows, be aware that you’ll spends lots of time tweaking two (or more) separate look-and-feels to match the OS-style.


#6

JUCE really good, recommended.

Drawback is that the font is not clear, a bit vague. The text font is too big by default .

I’m learning and exploring, I need someone teach me.