Newbie from Qt Land


I’ve been a long time Qt user working on internet collaboration tools, featuring audio/video conferencing, application sharing, content sharing, plus other fun stuff. Just happened across this site the other day and was both surprised, that I had never heard of it, and quite impressed, with just how much stuff could be produced by a “one man show”. So, anyway, just taking a cursory look and I did have a couple “getting started questions”:

  1. Real Qt support for mobile is just starting to be made available in the upcoming 5.1 release, so it would appear that JUCE is quite a bit ahead on this front. I can see that Android is the newer JUCE platform with iOS being more established. Could you identify reference applications (especially with live audio/video handling), actually released to either store, that could help us to evaluate the overall maturity of the toolkit on mobile?

  2. Saw a few posts regarding “integration of native iOS components” and also would have a requirement for the reverse of that “integrating toolkit components, including GUI, into a native application”. Could you comment on the current capabilities, or plans, for iOS and/or Android?

  3. Also saw a couple posts regarding performance concerns on mobile devices - are these still outstanding issues, or have they been resolved? From a UI perspective, we’re very sensitive to transition response times and really want to see that “instant POP effect without visual artifacts”, so, what would the current expectation be in this area, across platforms?

  4. Looks like JUCE is quite grounded in audio, with a strong emphasis on music/sound production. However, from a VOIP perspective, there doesn’t seem to be as much focus. Is there support for acoustic echo cancellation (I was unable to find it)? And, most of the code that we deal with (e.g. WebRTC) very much favors fixed point PCM samples (lightest overhead for building an efficient network stack), as opposed to floating point samples (I’m guessing that the music folks prefer this format). Again, forgive me if I’ve just overlooked something, but I couldn’t see any way to request integer samples, and to avoid any translations to floating point end-to-end (a primary goal for us)?

And, of course, I realize that noobster votes, especially those using other toolkits, don’t likely count for much, but I’ll throw out a couple opinions anyway.

  1. Core features vs. fancy gui builders - definitely core features. For instance, we have a team of very experienced, cross-platform Qt developers, and we rarely, if ever, use QtCreator, and we do not use the GUI builders for any of our layouts - in our opinion, MSDEV is just too good. Most of our work is done on windows, and then, based on the quality of our multi-platform toolkits, the work on other platforms is mostly left to handling corner cases. The whole GUI builder thing is highly over-rated, as it’s just not that difficult to code up precise layouts - without as much of the “RPG syndrome” that automated tools tend to introduce.

  2. All powerful build production environments vs. headers/libraries - of course, fully encapsulated static libraries. We would clearly think of JUCE as a sub-component on most platforms, as opposed to the master application component. So, in my opinion, it would be a big mistake to get too locked up into the whole IntroJucer/ProJucer concepts - which may actually impede the progress of those that would consume this as just one piece of a larger system, and may be selecting very different - and perhaps even way less cool - build production processes to smash everything together. I can integrate a static library into any environment and already consume several major libraries in just that way (fully avoiding extensive interaction with whatever build process they might think is pure magic) - so, for me, I definitely see some very nifty things in the JUCE library, but I don’t have a need for another development process/structure…



I agree that having IntroJucer and/or ProJucer required for practical development is a serious impediment to a lot of environments where there is already a well established and inflexible build process.

However, when it comes to integration JUCE’s “unity build” module structure is by far the easiest of all the choices, including the static library. Even without IntroJucer it is a trivial matter to add the handful (less than 13) of .cpp files to your existing project or Makefile. They don’t need any additional compiler settings or dependencies except for optional include paths for the Steinberg SDK or similar things. This is a lot better than having a static library.


Always glad to welcome defectors from Qt land! :slight_smile:

One of the things I’ve been promising to do for a long time is to add a static library mode for the introjucer - i.e. you’d create a project where you choose the juce modules you want, and set their various option flags, but instead of the target being an exe, it’ll build those modules into a static lib and generate some headers for it.

The main reason I don’t (and can’t) provide a juce static library “out of the box” is that it’s not a single library, it’s a collection of modules, with a whole heap of build flags that will be different for each project that you want to use it in. Personally, I’m a massive fan of simply including .cpps directly rather than messing about with platform-specific static libs and multiple build projects, but I know people seem to prefer libs for some mysterious reason.


Well, wouldn’t quite classify me as a defector - just checking things out, and we do have a pretty huge investment in Qt. At this point, we’d mostly be interested in some of the JUCE audio/video components, across five platforms, and perhaps a wider mix of components on select platforms (i.e. Android).

I didn’t really intend to get into a big discussion about build/dev processes. Suffice it to say that our project team consumes millions of lines of external C++ code, and we do it all with static libraries and headers (pretty much the most common, and basic, approach), so you might have other ways to consume JUCE, but it really does still need this standard method. I did see the “static” library" project, but it looked like it was only setup up for windows. So if this is what you’re referring to, but across all platforms, I think that would be a great way to support our needs (definitely, do not want you to ship binaries).

And, I hope I didn’t miss something with all these “options” that you’ve mentioned, but we’d definitely be hoping to “set them once and then forget them”. Sounds like Qt has a very similar problem, a giant build process with umpteen options. The good news, you figure them all out, build up your static libraries, then just link in what you need - all good until their next release, when they change everything around, yet again…

So, anyway, doesn’t look like build/dev would be an obstacle for us, so I’d be more interested in getting answers for questions 1 thru 4, and 5:

  1. Do you have a timeline for Android video capture? Are you looking at OpenMAX for this?



The old win32 static library project that’s in there is actually a bit out-of-date, it’s just been kept because a few people still use it. In more detail, what I was referring to above would be for me to add a new project type to introjucer, so that you could create a “library” project, then in it you’d choose your modules, set their options, etc, and then the project files it generates would be to compile a static lib with all that code.

(If I did that, I’d also have a related option which would let it export an amalgamated header/cpp pair instead of a static library, for inclusion directly into a project).

Re: existing apps on Android and iOS, I know people are releasing them but haven’t actually taken note of who they are… Any mobile users care to plug their app?

Integrating native iOS UI: It’s pretty simple to embed a native UIView - there’s a UIViewComponent class for it, like the OSX NSViewComponent.

Mobile performance: iOS should be no problem at all, it uses the native CoreGraphics. Android probably needs a bit more work because the only way to get decent performance is with GL, and I need to spend some time fine-tuning that… Wish I had more time to spend on Android!

Well, I’ve always made the audio platform-agnostic, since nowadays there’s not really much call for integer samples since they’re not really very easy to work with, and it doesn’t save any significant CPU time… The audio format readers/writers do provide integer samples, but for audio i/o there’s really not much sense in using integers.

Or both, ideally! I do agree, and core features are my favourite thing to write. But did you see the projucer preview video? The whole idea behind that is that old-fashioned GUI builders are useless for most code, because you rarely have anything simple enough for them to handle cleanly. So its main purpose is really just to speed up the turnaround time when working on a hand-coded GUI. Using it myself, I’ve already found it really useful in speeding up work on a whole bunch of components that could never have been handled by any kind of traditional GUI editor.

Android video capture: Haven’t had chance to research it, but yes, openMAX does seem like the way to go with that. My timeline is rather cluttered at the moment with Tracktion and some other side-projects, so not sure when I can get around to it, but I’d certainly like to see some camera action on android.


…FYI, this inspired me to take a quick look at the introjucer and do a bit of refactoring. It already had a most of the code for static lib generation, but I’ve tidied it up now, and it now has two new target types for static/dynamic libs, and the new project wizard will create these.

It should be able to build libs for mac/iOS/linux/windows; I’ve not had chance to look at android’s build system and figure that out yet, but the groundwork’s done and it’ll just take a bit of research to support that too.

I’ve also now removed that “extras/static library” folder, as you can use the introjucer to generate your own, with customised settings.


Why, Jules? Have you ignored everything I’ve been saying? Sure, we can generate our own now, but then we’ll have to do it every time you add or remove source files. Whereas before, you just incorporated it as part of your build process via script.


Because the version in the repo just dumbly included all the modules, set a random bunch of options for them, and exported only a 32-bit win32 library. If you do it yourself, you can choose the modules you want, choose the settings, and choose the platforms and platform options, and can create multiple different libs for multiple projects.


Because the version in the repo just dumbly included all the modules, set a random bunch of options for them, and exported only a 32-bit win32 library. If you do it yourself, you can choose the modules you want, choose the settings, and choose the platforms and platform options, and can create multiple different libs for multiple projects.[/quote]

Here’s the thing, I use the static library simply for browsing the sources. Without the static library, use of IntroJucer becomes mandatory if you want to do things like “Find in Files” from within the Visual Studio IDE. By taking away the static library project, you push the responsibility of keeping it up to date in N places where N = the number of repositories.

I can understand why you have a conceptual objection to maintaining the static library project because of the need to suit different needs in terms of settings and modules. What about if you call it the “Source Browsing” project instead of static library project? I.e. Extras/SourceBrowsing/JUCESources.vcxproj?

If you keep this part of JUCE then I won’t have to pointlessly run IntroJucer every time I pull a new JUCE branch. Remember that I use git-subtree to insert the entire JUCE repository as a subfolder of my own repositories (so that the repository stands alone). Without the IDE-specific project file (extras/static lib), this means that every time I pull the JUCE sources I have to also run IntroJucer to rebuild the project file in every repository. Compare this to how it would be if you simply kept the library project for browsing, which is that I need to do nothing except pull the JUCE tip.


As was mentioned, I also found this construct to be very useful for reviewing the code and, of course, it looked like a reasonable start on an easy way to produce a static library.

Sound like this would work fine. However, I should note that the idea of “choosing modules” is not relevant with the static library use pattern - just build the complete toolkit and let the linker pull out what it needs for any consumer (just don’t like the idea of having multiple subset versions floating around).

I can also see TheVinn’s point, that there would still be value in including the “standard” static lib projects, out of the box…

Similar structure planned for Android?

Yes! Android is what’s happening.

Hmmm, this is an interesting perspective. I guess the other side of the coin is that I’ve never seen a VOIP application that uses floating point. We’ve always assumed the main reason is performance (especially on ANY given platforms) and, so, why not lock in on fixed point? Some of the algorithms that we use do accept floating point inputs - but they’re ALL setup to expect fixed point samples…

Yes. Very slick. Very cool. The link into the LLVM P-Code thing is also quite sophisticated and a really neat concept. However, honestly, just don’t think we would use it.

Your code for windows video was one of the first things that caught my interest (no directshow_baseclasses), and then on Android, OpenSL audio, along with NDK video, is a good part of what we’re looking for. So, when I mention a preference for “Core features vs. whatever…”, this is what I’m really thinking about…


Personally, for code-browsing, I just keep the introjucer project open, and use that for searches, etc… Any of the example projects would do the job, I can’t see why you’d need a library project for that.

That would be great, but with such a broad library, it doesn’t work so well in practice… e.g. if someone is building a command-line app that just writes a few files, they shouldn’t need to install the VST SDK, the AudioUnit add-ons, QuickTime, DirectShow, etc just to compile it. To get the RTAS SDK you have to sign a license agreement with Avid, so I couldn’t make that a part of the library unless it could be turned off with a compiler switch. And there are plenty more examples like that in there!

And in my tests, linkers just don’t (or can’t) optimise a lot of this stuff away, meaning that vast amounts of spam get left in the finished exe. In a few years, hopefully the next c++ standard will specify a proper module system, in which case I’ll migrate my code over to that, but it’ll be a decade before everyone has that, so I think my current module format is the best compromise for the moment.

Well, the nature of this kind of project is that probably everybody reading this forum has a different idea of what their “core feature” is!


Actually, that’s a workable solution.


Actually, I was mostly using the JUCE demo to poke around. Of course, in the case where we had plugged your static library into our own code, we’d be using that project to “debug-in”, etc, as needed.

I agree with this. I guess some standard set of these was used to build the static lib example, and I had assumed it was a complete cut. However, still doesn’t matter, static lib means config/build everything once for each platform, then start working on our own code. Again, this is the exact pattern we use with the Qt libs (and others), massive process to build libraries (whatever “cool” thing they need) - still leaves you with gargantuous libraries - then rely on the linkers to sort things out. Perhaps not perfect optimization, but, works quite well on all platforms.

Anyway, the JUCE code is quite well encapsulated (I love that no external headers “pure C++” paradigm), so we really don’t even need help with integrating it into our dev process - we’re mostly discussing “nice to have” stuff.

Yes, of course. Just making it clear which parts are of interest to one potential customer. Which would be, Android first, real time audio conferencing (best latency/quality tradeoff, noise suppression and echo cancellation, hardware based if available), video capture (lowest latency, raw RGB), with a strong preference for the NDK/C++, Native Activity, side of that house. Also quite interested in accessing native (meaning the Java side in this context) widgets from the NDK side, to make the resulting application “look and feel” as close to a standard application as possible…

And, Android really is one of the big things happening these days, so I’m also wondering how much interest you’ve received from your current users?




There wasn’t much interest at all when I first supported it, but like you say, it’s growing fast.

I also have at least two side-projects of my own which will need to run on android eventually, both with heavy graphics requirements (one being a high-end video app), so it’s high on my radar. If there were a few more hours in the day, I’d be right on top of that!


So, perhaps, the other important question, are the new JUCE toolkit features mostly driven by the requirements of your other projects? While stirring up forum banter can be quite fun, just wondering if there are any other ways to influence priorities?


I guess if I had to analyse the main influences on what gets done, it’d be:

  • things I need for my own projects
  • things that a lot of people are moaning about
  • things that people bribe me to write for cold hard cash!


Good to know, we’ll definitely keep that in mind.