CppCast - JUCE

Episode Date: October 21, 2015

Rob and Jason are joined by Julian Storer to discuss the JUCE library. Jules has been developing audio and library software in C++ for over 15 years, and is the author of the JUCE library, the most widely used framework for audio applications and plugins. Music tech company ROLI acquired JUCE in 2014, and as well as continuing work on library itself, he helps to guide ROLI's other software projects. He also created the Tracktion audio workstation in 2002, which is still going strong and being used by thousands of recording musicians around the world. He lives in London, and likes to escape from the world of music technology by playing classical guitar News CppCon 2016 Call for Class Proposals Bjarne Stroustrup on the 30th anniversary of Cfront Do you prefer fast or precise? Julian Storer Julian Storer's GitHub Links CppCon 2015: Julian Storer "The Projucer" JUCE @JUCElibrary ROLI Tracktion

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. Episode 31 of CppCast with guest Julian Storer recorded October 21st, 2015. In this episode, we talk about the 30th anniversary of the first C++ compiler. Then we'll interview Julian Stork, author of The Juice Library. Julian will tell us about the history of for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner.

Jason, how are you doing today? Doing all right, Rob. I just submitted a talk proposal for accu in bristol we'll see how that goes really okay yeah that's coming up in april april okay what about meeting c++ you think about going to that one too uh no no december in germany is not a great time for us right now okay i, I understand that. We'll have to look into ACCU. I'm not sure if I can make it over to Europe this year, but I'm definitely excited for next year's CPPCon.

Yes. Yeah. Well, at the top of every episode, I'd like to read a piece of feedback. This week, Patrice Roy was sending us some messages on Twitter. Patrice is on his way to Kona for the ISO C++ meeting, and he was listening to CppCast on the way. It looked like he listened to the Anthony Williams, Kate Gregory, JF Bastion, Sean Perrin, and James McNallis episodes.

He says, way to make a trip interesting. Some good ones. Yeah, some very good episodes. So we'd always love to hear your thoughts about the show. You can email us at feedback at cppcast.com follow us on twitter at twitter.com cppcast and like us on facebook or you can always review us on itunes as well and we always really appreciate the itunes reviews they help us get more listeners so joining us today is julian storer julian has been developing

audio and library software in C++ for 15 years and is the author of the Juice library, the most widely used framework for audio applications and plugins. Music tech company Rolly acquired Juice in 2014 and as well as continuing work on library itself, he helps to guide Rolly's other software projects. He also created the Traction audio workstation in 2002, which is still going strong

and being used by thousands of recording musicians around the world. He lives in London and likes to escape from the world of music technology to play classical guitar. Jules, welcome to the show. Thank you very much. It's great to be here. So what is this Traction Audio Workstation? Well, I'm actually using it right now to record my side of the audio here so um hopefully your your audience will hear glitch free recording of what i'm saying um it's i mean to anyone who's not familiar a digital audio workstation is um it's a piece of software that does um audio recording it's what you use in a studio to record instruments and to sequence synthesizers and that kind of thing. And yeah, sorry.

So is this a software that's used by like major recording studios for musicians? It's one of the many. It's quite a crowded market. There's probably about maybe 10 really well-known workstations that people use. It's a strange market because unlike word processors where there was only ever really one or two, in this market there's quite a lot of pretty similar competing products. Interesting.

Very interesting. So we had a couple of news items to go through before we talk to you, Jules, but feel free to join in. The first one is that CppCon 2016 is already getting started and they're looking for class proposals. Now, Jason, did you go to the CppCon 2015 class that they had? No, I didn't. That was like the day before the conference started

and I showed up the next day. Okay, but I guess they're looking for more content similar to that. Did you hear anything about the class at 2015? I actually didn't. I didn't even, like, it didn't really hit my radar. I didn't think to ask about it. I'm sorry. I don't have anything interesting to say.

It's okay. Well, if you're a C++ instructor, then reach out to the CppCon committee, and maybe they'll be interested in having you give your class for 2016. The next article is this interview with Bjorn Struestrup because we just hit the 30th anniversary of the first C++ compiler, Cfront. And it was a really interesting article interview with Bjorn kind of about how that came to be in the writing of the c++ book that was released on the same day as the first compiler jason what were your thoughts on this one well largely i thought the uh the reddit conversation was interesting and i

you know sometimes i tend to bring it back to reddit here but uh here, but it's a fun conversation because you've got Bjarne actually talking and sharing on Reddit. And people are like, whoa, wait, I didn't know you were on Reddit. And it just makes some good discussion, conversation, feedback. It's neat. Yeah, absolutely. How about you, Jules? Do you have a chance to look through this? Yeah, it's 30 years, eh?

It was really interesting, actually, at CppCon to see Bjarnas' talks and the new stuff he's pushing for. That made quite a big impact on me and the guys, and we're going to try and push as much of the kind of stuff he's saying into Juice, into our library as we can. Yeah, one interesting thing in the interview is he was asked if he ever tried leaving C++ or went to go build a second language. And he said he was tempted to at some points, but C++ kept pulling him back.

And I'm definitely very glad that he's still in the community, still working to make C++ better because this new work with the GSL just seems great. Yeah, really cool stuff. Yeah. So the last one is from the Visual C++ team, and they're actually looking for some feedback here. Apparently, there are two flags to decide how floating points are handled from the compiler. There's either FP fast or FP precise. And they're basically asking what the default should be,

fast or precise with floating points. And currently it's precise. And I don't know about you guys, but I kind of feel like precise should remain the default. We always want speed, but I don't think we want speed at the sacrifice of precision. I would agree with you until you get to that point

where they point out that FP-Fast can use some of the vectorization parts of the CPU, which actually results in more precise results, even though it's faster. So, that's the end of the counter under the counter example heading in there

interesting to read yeah this is this is quite an interesting one for the kind of work that i do because in audio we always seem to end up turning on fast um and it was interesting that i'd actually argue the opposite way about defaults because if you start with something that's precise, if you write quite a large app with precise, and then you enable fast, you can actually end up with some very subtle errors creeping in that you don't notice. So everything might seem good,

but then you'll have some weird edge case where a number will go wrong because of the fast flag. But if you kind of started the other way around and everything was fast by default, you'd get those surprises straight away. You'd see these errors creeping in when you write that bit of code. And then if you find that something isn't precise enough, you'd say, well, I'm precise, and everything slows down,

but nothing will actually go wrong. So I don't know. It's a difficult one. I can see the dilemma there. Really interesting way to think about it. And I've got to say, too, reading this article, something just kept bothering me the whole time. They kept saying there are two types, float and double, float and double, and ignores that long double was added in C++11.

There are three floating point types in C++. Do you know if any of the other compilers have similar options with regards to floating points? I know GCC has some, but I've never played with them myself. Never had a need to. No, we sometimes will tweak a few around and see what effect they have on performance when we're really pushing on something,

but I've never dug deeply into what the possibilities are there. Interesting. Okay, well, Jules, let's start talking to you about Juice. Could you start with an overview of what Juice is? Sure. It's a big C++ framework. It started off as um an audio framework but then you find that when you're writing audio apps you actually tend to do more than just audio and you end up needing graphics and gui stuff and all sorts of support classes so over the years

juice has gone from um something very small to to being something a little a little bit like the cute framework or wx widgets that kind of that kind of um uh spanning that that is this kind of areas so um it's it's very heavily used in the audio industry because that's where my background is and the library itself spun out of traction which was an audio workstation so it got taken up by a lot of people we knew who were developing audio plugins and became pretty dominant in that area but probably only 10% of the library is actually audio code the rest is a big GUI framework, basic container classes, network, cryptography, a whole range of different support tasks. And the idea is that you can build most audio apps or audio plugins

or kind of multimedia apps without really needing any other libraries. And it's cross-platform, is that right? It's cross-platform, is that right? It's cross-platform, yeah. It runs on Mac, Windows, Linux, iPhone, and Android. And we're also planning on working on a bare metal version of it to run on bare metal Cortex processors in the new year. What do you mean by that? Actually, being able to run it

without an operating system. So, yeah. It's broad enough that we could do that. One of our little side projects at Roli is working on a little embedded board with a very bare metal processor on.

Being able to actually build juice apps. So you can test an app running on your desktop machine but then recompile it to run on this bare metal board with no operating system and get as much functionality as we can out of that interesting and sorry i interrupted what you were saying a minute ago if i don't know if you remember what it was or not what your train of thought was there uh no sorry that's all right so it started off um in the audio world are there a lot of applications you know of outside of audio and multimedia frameworks that are using juice we have a few um i mean we don't know what everybody's doing with it because it's open source and people are out there using it for

all kinds of things um and we yeah we we've we've had a few people get in touch who have used it for things like games. I'd love to see it being used in more games because it'd be a great framework for that. But at the moment, our kind of core basis is in the audio world. So having used a lot of cross-platform GUi toolkits i really do not envy you for having developed your own i'm curious what's some of the more interesting challenges that you've come across or roadblocks or pains or anything any stories you'd like to share yeah well the most to be honest over the years the most painful bit wasn't the GUI stuff. It was the plugin framework. So for people who aren't familiar with audio plugins,

the way a lot of audio software works is you have a host program, and then you have little plugin effects units or synthesizers, and there are thousands of these out there. And you'll take a synthesizer, you'll have another plugin, which is some sort of reverb or effect. There are different formats for writing these plugins. There are about three different formats that are commonly used, and we support all of these in Juice.

They all run on all different platforms. We have several plugin formats. Multiply that by several platforms multiply that by maybe uh 20 different host programs that can be loading these and then bear in mind that these formats were written uh quite not designed with too much thought a number quite a few years ago and that over the years you know that you had the hope that people writing the hosts and people writing the plugins not quite agreeing on what the protocols are um so having written a framework that people used to build the plugins and a framework that people used to build the hosts and building my own host. And this combination of possible places for things to go wrong has been crazy.

So, yeah, over the years, that's definitely been the biggest pain point. Doing the GUI framework, by contrast, has actually been really quite good fun and pretty easy because that's all quite self-contained. You know, you write a button. Okay, you have a lot of people asking for hey i would write the button that does this that and the other but it's quite straightforward you know get the pixels in the right place get the mouse clicks in the right and deal with them it's fine but um dealing with all the third party interactions has been the the worst thing over

the years so are these like compiled binary plugins or Absolutely, yeah. So if they go bang, they go bang and take the whole application down. Now, if you have an x86 compiled one, you can't run it on your Android port, I assume. No, no. And when Android does support plugins, which I'm sure they will do pretty soon, I think that might use sandboxing or something to communicate between the plugin and the host as if they're different apps.

But on the desktop machines and the way most things are used at the moment, the plugins are basically DLLs. They get loaded into the host address space so they get free reign to destroy as much memory as they like which is which creates some fun situations and it it's also means that if you're a plugin developer and you launch a plugin and it crashes the host it seems like if you if

if you launch the plugin and it crashes the host the users complain to you but if you write the host and someone else's plugin crashes your host it seems like the you launch the plugin and it crushes the host, the users complain to you. But if you write the host and someone else's plugin crushes your host, it seems like the users still complain to you somehow. Right. You always seem to get the blame, no matter which side of the fence you're on. Do you have any favorite tools or anything for debugging what this Blackbox plugin you've got is doing?

Yeah, guesswork, mainly. Okay. And reaching for an email and writing to the people who actually wrote the plugin and saying, guys, please run this and debug it. Because quite often you simply have no idea what's going on in there. That's interesting.

And the number of edge cases, even with a simple API for a plugin, are really enormous. When people don't quite know what thread they're going to be called on, and they write it expecting this function to be called before that function,

it's just a crazy number of possibilities for people to test. So they don't. Wow. Okay. I wanted to interrupt this discussion for just a moment to bring you a word from our sponsor, JetBrains. C-Line is a cross-platform IDE for C and C++ from JetBrains.

It relies on the well-known CMake build system and offers lots of goodies and smartness that can make your life a lot easier. CLion natively supports C and C++, including C++11 standard, libc++, and boost. You can instantly navigate to a symbol's declaration or usages too. And whenever you use CLion's code refactoring, you can be sure your changes are applied safely throughout the whole code base. Use Subversion, Git, GitHub, Mercurial, CVS, Perforce via plugin, and TFS with a unified interface for all of those. Run a terminal inside the IDE and install one of the dozen of plugins like Vim Emulation Mode, for example.

Download the trial version and learn more at jb.gg slash cppcast dash clion and use the following coupon code to get a 20% discount So this might be jumping ahead a little bit, but you're describing this big problem with all these different platforms and different plugin specifications. Does Juice do anything to try to help this problem for the plugin developers? Well, yeah. I mean, we I mean, that's why a lot of, most of them use

our libraries because it takes a lot of that mess out of there and they write that plugin with one with just two hour API and then we wrap it in the different third party ones and we try to take the pain away but

we still can't stop plugin developers doing silly things inside their code and causing problems we do our best the one good thing we do though is that we have both the host and the plugin API so

and it's all open source. So we can always say to people, hey, if your plugin seems to be crashing a host, then try it in our open source host, and you can see exactly what's going on at every level. So have you considered any of the esoteric sandboxing or emulation environments like Chrome uses to sandbox its plugins from the web browser?

Yeah, interaction actually, we've been investigating that fairly recently and some of the other workstations do seem to manage to host some plugins in a separate process. But with audio, this is a real pain because with audio, the problem is all about latency. You're playing these tiny audio buffers and each one has to be filled within maybe a millisecond or two. And the slightest overrun will cause a really nasty audible glitch

that people will complain about. So, you know, that's a hard problem even when you're running one process with all of your plugins running in the same address space and a function call is simply a function call into that plugin. But once you move some of that functionality out into a separate process and you have to communicate with it through shared memory with signals, and automatically you're on separate threads and these threads are running in different process spaces, that latency problem becomes very, very nasty because if you have a chain of say a hundred plugins, which isn't unusual and you have,

um, a time of maybe, uh, three or four milliseconds in which to send a piece of data to each of those plugins and wait for it to process it and then respond and then pass the, pass the result onto the next plugin. This becomes like ridiculously, um,

hard to achieve without things going wrong. So people have got sandboxing working. We've been looking at it, and it's actually one of the most difficult problems I've actually tried to solve. I can imagine. Yeah, the hard real-time side of it is very, very nasty. So the Juice library was originally

developed kind of solely by you. Is that correct? And just over the past few years, you moved into the open source world? It's always been open source. Okay. It kind of branched out of the traction, the workstation I was writing back in the early

2000s. Because back then, there wasn't really a good library to use, so I started writing my own little bits and pieces, ended up getting carried away writing a whole GUI framework and then branched that out. But as soon as I branched this out, I took it open source. So it's been open source for more than 10 years now. And it was just me working on it until last year

when Rowly got involved and um and now we have a little team of um five of us do you get contributions from outside of roly um people the most useful thing people send are bug fixes um occasionally we we get people contributing a little snippet of code that helps them do something they were trying to do. We don't take pull requests because it always needs rewriting. So even the best code we get, it's kind of never quite right.

So we always review and rewrite. So you have a major release coming up soon, right? Yeah, it? Yeah. It's interesting. Juice version 4 is going to be the first one where we've actually held back some functionality, and then we're going to say on a certain date, hey, it's released. The way I always did this in the past was

that everything I ever did just went straight onto the Git repository. And at some point, I would decide that, hey, that feels like it's about a release candidate, and then I'd tag it. So this time we're doing things in a slightly more grown-up way, and we've actually got a bunch of features that we're doing on branches, and we'll merge them all in on the day that we decide it's the G4 release day. So are there any features you would like to highlight?

Yeah, we've got a few good ones. I mean, the big one for us is the producer, which is our... I hesitate to call it an IDE. It's a live coding tool, sort of a playground-type exploration tool. It'll take your code and compile it, and then it can instantiate classes on their own

and run them in Windows and let you change the code and see the results in real time while it recompiles in the background. It's very hard to explain without showing it, but it's something I've been working on for more than three years now. I first demoed it about three years ago,

and we're finally going to get this out to the public. So I've been going around talking about it a lot and showing it to people, but yeah, it's finally going to hit the shelves next month. So I saw a brief demo of this at CBPCon. Yeah. So you can, maybe for our listeners, if they can visualize this, you can have whatever, a widget on the screen,

and change a number in your code for the size of the widget, for example, maybe, and have it immediately show the effects in your running live code. Is that correct? That's right, yeah. Yeah, we do it with an embedded LLVM compiler and some cunning tricks. So things like when it's compiling, it'll replace all the literals

with special secret global variables that can be changed while it's running. We also use tricks like it'll compile as little of the program as it can get away with, so you can have turnaround times of about a second, even if it has to actually syntactically recompile stuff. So it was inspired years ago by this demonstration that a guy called Brett Victor did, which made a big hit.

And he was showing this equivalent kind of thing, but using JavaScript, where he changed things in LiveCode and you could immediately see the results. And I basically tried to have a go of doing that in C++, and this is the result. So we're not really expecting people to use this as a full-blown IDE, but it's more for when you're working on one little piece of code, and maybe you're trying to get a piece of graphic design correct,

or synthesize an algorithm correct, and you're just fiddling with one little piece of code repeatedly. And rather than having to sit and wait and recompile and restart your app and go and find that page again in the app and see what the result is, you can just leave a window up at the side, and as you're changing the code and tweaking it, you'll see the results changing until it looks right.

And, yeah, we've already been finding it pretty useful internally. It sounds incredibly powerful for the GUI application development. Yeah, for GUIs it's a really big deal. But also now we've got some audio stuff going as well. It's also pretty useful for that. And it's extendable enough that people will probably find other uses for it. And is Projuicer also open source? It's not.

It's based on our other tool, the Introducer, which is open source, but the Projuicer itself isn't. Mainly because the actual build process involving LLVM is quite complicated, so it makes more sense for us to keep it closed source and distribute that like a normal, regular old-fashioned app. Okay. So what other features are there in Projuicer? It's really all about live coding.

I mean, the other things that it does are in the open source introducer, which are the project management functionality that it has. It's basically, I mean, this tool's been around in Juice for quite a few years now, but it lets you manage a whole project and export it for different IDEs so that you manage one set of files and one set of settings and then you can export that for Visual Studio, Xcode, and different compilers. We use this in all our teams at Roli and Traction

for managing our cross-platform builds because when you're actually targeting four or five platforms and you add a file, it's just a real pain in the neck to go through all of those projects and keep them all in sync. So people use things like CMake. We've got our visual tool for that.

So that's the main thing that people use this for. Okay. I saw there's also a new module being added to Juice with this release, the OSC module. Can you tell us about that? Yeah, OSC stands for Open Sound Control, I think. I think that's right. And it was originally intended as a replacement for the old audio MIDI standard,

which is the format that's used for communicating with synthesizer keyboards and things. And OSC is a very generic data transport mechanism. You can send just changes in named parameters across network connections. So, yeah, it's pretty widely used in music and also in things like live control of interactive graphic displays and this kind of thing. So, yeah, it's been a feature that people have requested quite a lot for years.

So we finally implemented it, and we're pretty proud of it because it's, I think ours is the only really fully, fully featured implementation that actually meets all the standards. Um, we looked at lots of others. Um, yeah, we tried to, it was a really nearly API so that we covered everything that the standard says, but also did it in a really usable way kind of sounds like now that you've got some corporate backing of your project in the last couple of years you've managed to you're able to roll out new features faster maybe yeah it's nice to be able to parallelize a bit yeah i can send send off a few threads and then they will come back and i join them and

and review all the changes and it's working pretty well. That sounds pretty nice actually. I could use that. Use a couple more Jasons? Or something. It's good. And with a project like G Suite we have so many different sub-features.

It's a problem that parallelizes pretty well. Is there anything else you'd like to brag on about the new upcoming release or the project in general? I don't want to harp on about it too much. People, I'm sure, will discover it. Yeah, no, I hope we get a few more non-audio people who hear the podcast and check it out, to be honest,

because, yeah, we're good for audio people, but I'd love more games people to discover it and more people doing sort of general apps in other fields. Come and check it out and tell us what you think of the projects and where you think we should go. You know, I personally make a point of following cross-platform libraries whenever I see news about them. I want to follow up on them.

And I don't know how, but Juice had completely missed my radar until I heard about it at CppCon. Right. You see, I hear that a lot, which is strange, because in our little world, it's really well-known. But you go outside the audio world, and somehow it's not hitting people's radars. Interesting. world and somehow it's uh yeah it's not hitting people's radars interesting um is the gui toolkit in juice pretty expansive like with the types of controls you can build with it um is there any shortcomings with what you can and can't build with the gui kit it's um it's pretty expansive

i mean the thing the thing about um audio stuff is lots and lots of audio tools have really customized GUIs. You see these really people come up with these crazy interfaces for all of their weird synthesizers and weird effects. So actually probably most of the things you see written in Juice don't look like Juice interfaces. They're things that people have completely customized down to the pixel level. So we try to make sure that's possible. Cool.

I also see this thing on the website about high-quality C++, how you intend for every class to be an example of best possible coding practices. How do you live up to such a high standard? Obsessively. Yeah, no, it's one of those things like when you're doing a public project list and you're getting people looking at your code, it forces you to take more of a pride in it so um and and one of the compliments i've had over the years is that people people say once they

once they've learned their way around the toolkit they kind of know where to find things they know they know what to expect something to be called because they kind of get the overall personality of it so this is something that while we are parallelizing and trying to get more people generating code for it, we're trying to keep that overall consistency and the overall personality of it the same by me really obsessing over every line that goes in, every character, every space in particular. But yeah, we do try to not just write code

that works and works efficiently, but which is a good example and a good example for people to follow. Is library... It's really important. I'm sorry. Is library using the latest compiler version, C++14? Oh, I wish we could.

Oh, okay. We can't even go to fully C++11 yet. We have a user base where we've still got that little portion who are stuck on the old C++03 compilers. Okay. And at some point, we're going to have to give them some hard love and say, sorry, guys, move on now. And we've obviously incorporated some C++11 stuff

with if-defs around it to make sure that it'll only be used and available on people who do have C++11. But the whole team are really looking forward to the day we can say, right, delete the old code. And we're going, it's all C++11 from now on. Because the library actually predates a bunch of stuff. It obviously predates things like the standard threading

and the atomics and some of the new nicer containers we've got. So, Juice actually contains all that stuff that I wrote a long time ago because we needed it. And it'd be really nice to be able to ditch that and move on and use the standard stuff that comes with all the compilers now. Yeah. So the Juice Summit is coming

up soon. Is there anything else you wanted to share about that? Yeah, we're really excited. This is going to be our first actual Juice event, conference. We've got, it's a two-day conference on November the 19th and 20th. It's in London

near our Roli's trendy East London offices and we've got some great speakers, a really packed program for two days, we've got some terrific speakers in, we've got a bunch of the guys from Google's Android team who do the audio actually the real coders

so they're coming in to talk to us about that, we've got um a guy called pete goodliffe who if you go to acc you'll probably see him there he's one of the the regular keynote speakers from that and he works as akai and um writes books about good programming and he's just a really great sort of inspiring speaker we've got um we've got a special guest not sure we can announce yet um and we've just been and this week we've just had in our submissions from users and we've had um i can't remember how many maybe 15 really great talks like wow on that so we it's gonna be two days of really packed um packed uh packed schedule.

It's mostly audio related, but we'll just have to see who turns up and what they want to talk about. Very cool. Well, is there anything else you wanted to share before we let you go, Julian? No, that's good. I've plugged my library in our event, so

that's terrific. Okay, well, where should people go to find more information about juice itself and more information about you juice.com is the place to start um juice that's juice without an i that's j-u-c-e and uh or roly.com and from there i'm sure you'll be able to find find your way to to me or to any other resources you need okay well thank you so much for your time. Thanks very much. Thank you.

Cheers. Thanks so much for listening as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, I'd love to hear that also. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.