Luke from Sonnox

When it comes to maintaining a large library of audio plugins, "Use JUCE or have a hard time!" is Luke Maycock's primary recommendation. Luke shares strategic details with the JUCE team on how Sonnox maintains hundreds of JUCE binaries, including prestigious products with roots in the 1990s.

Your JUCE forum posts on CPU blurring got me deeply interested in that topic. You're partially responsible for what turned into a three-month rabbit hole for me!

I'm really sorry. But it was born out of necessity. When you've got a team of designers who here saying "We want our UI to look like this" and then you've got your GUI code that says "No, you can't do your UI like that," sometimes you have to try to solve things by yourself. And unfortunately it does end up sometimes roping other people into three-month projects and I'm very sorry.

[laughs] Well, I was happy to be roped in. My UIs are all vector based, so it was something I wanted to figure out more deeply. Does Sonnox have in-house designers or do you contract out?

No, we do have a couple of the guys here that work in the more product design side of things. We're a really weird size of company. I'd love for us to hire a designer. But yeah, at the moment we're not really quite big enough.

How large is Sonnox?

If you counted everybody, I think it's about 18 people.

I mean, some people do a lot of this by themselves. That's what gets me, you know? I've worked at Sonnox for 10 years. At that time, we started with 12 products. Now we've got 19. You might have a big team of people around you, but you've got a lot of work to do trying to maintain and develop new products and do all the sales and marketing stuff. Just selling stuff around the world is difficult and quite an involved process, let alone the technical side of things.

So yeah, I don't really get how people do this in two or three people teams. These guys are crazy.

Yeah, I don't understand it either! It just seems like nobody can be good at everything? You can't have one person that's good at DSP, good at UI, good at marketing, good at selling...

Yeah, this isn't an industry of "if you build it, they will come." You have to really be able to make products that people want. But not only that, you have to tell people that it exists.

Software, in a way, is harder because you can't physically put it in front of a person and say "Hey, have this" while you're just walking down the high street one day. You need to find where people are. You need to get that stuff to them. And you need to make it appealing.

And yeah, things like drop shadows and UI are such a kind of modern.... fad isn't the right word—

Requirement is a good word!

Expectation. Let's use the word expectation. If your GUI is all flat looking, some people like that, but some people like super skeuomorphic, 3D rendered, OpenGL, etc. You've got to try and please everyone. And then that kind of psuedo-skeuomorphic "Hey, I've got shadows all over the place but the implied light source is technically everywhere all at once."

[laughs] There's definitely room for all kinds of design. Audio is such a creative space.

There was one plugin I saw. I can't remember what it was called but it looked like it had a garden-themed UI. In between the high and low-pass handles it had tall grass. And as you moved the filter, it cut the grass. That was so cool! [Luke later found it: GreenHAAS by Mixing Night]

There's another plugin company [Freakshow Industries] that just makes the most bizarre plugins that you've ever seen. They make crazy sounds. The UIs are just flashing random pictures up at you and they're completely weird. They stick in my memory. Because they're memorable, you know?

They're different!

Yeah, the way that they sound isn't even necessarily what catches me. I remember it because it looked funny. It looked different. It was interesting. It's not just another stock DAW EQ with a functional interface. There was something about it. And for some people, it's coded in shadows and gradients.

I like this outlook because it shows how much room there is for — I don't want to say novelty, because that diminishes it — but a wide gamut of creativity.

Yeah, absolutely. There are two elements to plugins. There is how it sounds. And there's how it looks.

And both are really important. Because your plugin can sound absolutely incredible. It can be the best DSP, the most efficient. The cleanest sounding or the dirtiest sounding (depending on what you are going for). It can absolutely achieve what you want, but if nobody can get that out of it, because your UI sucks or your choice of parameter ranges is wrong or you've not exposed a part of the algorithm or you've hidden things behind meta parameters — it's a really hard balance to strike.

And then you have to maintain that forever. This is the other thing...

Yeah, lets talk about maintenance. There's some debate about how many binaries you're maintaining. Some numbers were thrown out, like 250?...

Yeah, if you take into account VST3, AU, AAX Native, AAX DSP and some VST2s that we supply for UAD. We've dropped 32-bit now so it's only 64-bit. But then there's Windows 64-bit, there's Intel based Macs, ARM64 on Macs. We've got 19 products. We've got one product that also has an iOS app. And an Android app and a system driver. Two of our codec-related products also have standalone apps.

When there's a JUCE update (all of our products use it), that's for hundreds and hundreds of binaries. All of a sudden you think "Man, I've got to test that".

I can make one commit and generate — my last count was 231 binaries.

And it's all under Continuous Integration (CI)?

Right, so we use GitLab. We have an internal instance of GitLab. And we have a server room in our office with all the runners on. And we do pluginval. Pluginval is great. It's my favorite thing. It just tests so, so much. It's caught so many bugs.

Before we were automating tests with pluginval, we were delivering installers to our QA guys,
and they were immediately bouncing it back to us saying, "I installed that, I opened my DAW, it crashed."

That hasn't happened for years.

And we've got unit tests. It's the principle of shifting a problem left: the earlier you catch problems, the cheaper and easier they are to fix.

Can we talk about unit tests a bit?

Yeah, of course. We've got unit tests in all of our DSP.

Our DSP library is kind of in three layers. The first is what would be analogous to JUCE FloatVectorOperations, which at compile time decides "Am I going to run Apple Accelerate or Intel IPP?"

Are you testing the vendor implementations of vector operations?

Not quite. We were using Intel IPP on Mac and Windows, because at the time that made sense. Then Apple comes along, throws us a curveball of a completely new architecture. So what I did then was basically write unit tests for every vectorized function that I had wrapped up.

And as you can attest — because I've read your blog post — Intel's naming standards are hard work, right? So part of the reason I wrapped the Intel IPP stuff up was so that I could conform their functions to our coding standards and it's actually readable.

So now the challenge is, what that function does can differ if I'm running on an Apple Silicon machine or an Intel Windows machine. So I wrote unit tests for every single function and said "This is exactly how they are expected to operate." Then I wrote the implementations for all the Apple Silicon implementation and made sure the tests worked.

Again, shift the problem left: the earlier you can catch something's not going to work, the quicker and cheaper it is to fix. And when you've got 19 products, if you catch that when every product's just been released and out the door, that's going to be a very expensive thing to try to fix.

I like this concept, shift it left. I haven't heard it before. What testing framework are you using?

We used to use JUCE's unit test library for that. I've just migrated everything on the unit test level to CMake and Catch2. Catch2 can be a bit fiddly but it's incredible powerful. Just things like the ability to template a test case. It's so cool.

When we're at the the [unit test] level, it's super strict. If I've got a vector and all of their values are 1.0 and I scale every one of those by 0.5, it better be 0.5 when it comes back out, regardless of platform.

Exact, but with float inaccuracies allowed?

Yeah, we're using the standard library numerical limits. Because yeah, especially with float instead of double, you have that rounding error. But accounting for the rounding error, we're pretty damn strict.

Because otherwise things could sound completely different. If you've got a threshold parameter and it's set at some very exact value if now you've got some rounding error, that could be the difference between your threshold triggering and not.

So I said we have three different levels. There's that IPP/Accelerate wrapper and then built on top of that are the building blocks: delay, buffers, FFT, convolution — those utilities.

And then on the top level is the algorithms themselves for the products. We're starting with sanity testing. So again, on all those target architectures, Windows, Intel Macs, ARM Macs, does the algorithm work? Does it explode? Does it start returning INFs or NANs? Does it just drop to silence after a few blocks of processing?

We're randomizing parameter values and just kind of chucking every possible random combination of different parameters and testing all the different signal paths and just making sure that everything is stable.

Once you've released a plugin, you can't just go and change things about it. You can't change the fundamental way that it sounds. Once you put that v1 of a product out there, it almost becomes set in stone. That's how it sounds. You can make improvements to the UI. You can add shadows all day long. But the DSP has to stay the same.

Especially for us at Sonnox. We have products that existed before our company existed. The Oxford EQ, the Inflator, the Dynamics. These were things that were originally in a hardware console.

Original Sony Oxford Powercore Plug-ins packaging from the early 2000s.

Can you tell me more bit about that? It's kind of mind blowing. This was a digital console?

Yes, it was a Sony-owned digital audio console [the OXF-R3]. And as DAWs came around, plugins became a thing, ProTools was happening, there was a transition of saying "Well, we've got these algorithms, we could put them in plugins."

Sony lost appetite for that. There was basically a management buyout of the plugin side and they took the algorithms that were in the digital console and here we are now. But that means that there are sessions out there in an old version of ProTools — somebody's got an Oxford EQ that existed before this company existed — you know they're going to come to us one day and say "Hey, that product is still called the Oxford EQ and it's still got the same DSP, I want to update it now, please"

Right! [laughs]

Oh, you are laughing, but you can do that! We will take your RTAS chunk and we will load into our lovely JUCE AAX plugin!

You also ship some products that run inside of modern digital consoles?

There's the [Avid Venue] S6L, S3L. They're like in-the-box Windows systems with a console interface slapped on top. And yeah, we've got Avid HDX DSP plugins that are built with JUCE that run on those consoles.

So the DSP that originated in a console, has been taken out of the console, wrapped in a plugin and then put back in a console.

[laughs] Yes.

Ok, I just wanted to make sure I got that clear. You seem to be a maestro of porting.

Yes, we have ported! When I started working here, 10 and a half years ago, we didn't use JUCE. We had our own framework, which was kinda like JUCE but I'm so happy we don't use it anymore.

The amount of work that the guys at JUCE have to do just to keep things running.... It takes all the pressure off of me. I don't want to have to deal with Apple Silicon. I don't want to have to deal with Windows DPI support or VST3.

Those guys solve big problems for me before I even have to think about it. That's ultimately the benefit of JUCE. If you're not using JUCE these days, especially to make audio plugins, you're just making work for yourself.

[laughs] That'll be the pull quote of the article!

"Use JUCE or have a hard time!"

Did you play with the Direct2D renderer on Windows yet?

So, I met Matt [Gonzalez] at ADC. We had some great conversation. Matt's a really nice guy. And he's done some absolutely incredible work. That took so much time and dedication and skill. I'm blown away by how much he's done.

I'm trying to pull forward our version of JUCE. We're currently kind of stuck on 7.0.3. There's a couple of reasons. One of them is that they've moved the wrappers. I don't know in git if you've ever tried to deal with two branches where one has changed a file and one has moved it...

Oh, I have stories about that. Are you running a JUCE fork?

Yeah, we have our own JUCE fork. We've got some changes in there, but I'm slowly getting rid of them. I'm trying to step us forward and deal with re-implementing our changes on top of each version of JUCE until I can get to that holy land that is the Direct2D preview branch.

Any time you think "I need JUCE to do something different, I'm just going to patch it myself" you've then got to maintain that patch forever and ever. We made patches to JUCE six, seven, eight years ago when we started using it. I still have to keep those alive because I've built products around some of the stuff I put in there.

I've pulled a lot of that stuff out. We implemented things like parameter attachments before they were a part of the framework. And then JUCE did them slightly differently than we did. But then it's like, "Well, I've got how many hundreds of parameters and hundreds of GUI controls across so many products. Do I just delete our version and use the JUCE version? Or do I leave it there? How much time am I going to take to delete all of this code and port everything over?" Again, I've used the word "port!"

Sometimes you end up having to make the decision "I just have to leave this code here."

People tend to hate on maintenance, but I love it. It's so multi-faceted. There's all these hard questions in terms of what's worth it. It's can be very counterintuitive.

Yeah, we've got a couple products in particular whose code bases are really old. And I'm scared to touch them because they "work," right? If the code works, then sometimes you've got to work around that and leave it as is. Because the risk is, again, especially if it's super ancient DSP code, you don't have to touch that stuff. Sometimes your effort is better spent doing other things.

Ultimately, for me, I have to remember that I work at a company that's not mine. I don't necessarily have the ability to say I'm going to spend the next two years rewriting all of our product code from the ground up. There's a lot of other people that work at this company that rely on products that we make to pay their mortgages, feed their children.

Speaking of, are you working out of the Manor right now? Does everyone work out of this cool British barn?

We're kind of in rural Oxfordshire. Our office is on the Cornbury Estate. We're right on the edge of the Cotswolds. I can see cows in the fields.

We like being together as a team. To sit in a physical space and turn around to each other and just go "ah what the bloody hell is this code doing?" When we're trying to hire people — I think it kind of goes against the norm at the moment — we like to try and encourage people as much as possible to be in the office, to be physically here.

So you live in the area also?

The next town over is called Charlbury, and that's where I actually grew up.

I did a music technology undergrad degree at Coventry University and really got into plugins there. I taught myself C++ in my final year instead of the doing the work I was supposed to be doing. It was more interesting to learn C++ and learn about plugins. And then I came back and thought "That's what I want to do. I want to make plugins. That looks like fun." I realized that literally a three minute drive from my house was Sonnox. And Rod [Densham] gave me a job.

While I was here I did a part-time master's degree at Queen Mary. So I was here somewhere between full-time and part-time. I'd finish a few hours early and then I'd go home and do my master's degree in digital audio progressing. So I've got a fair understanding of what's under the hood. I don't get to use the DSP knowledge much because I'm stuck in maintenance land.

You're busy living the porting life.

I am too busy living that porting dream.

Anything else you want to get on the record?

JUCE is great. That's pretty much it.

[JUCE director] Tom is going to love this interview!

There was a reason he asked us to talk! He knew I was going to say that.

But it's true. I've done this for a long time at Sonnox. I can only speak from my experience and our experience as a team. But I think our experience is a lot better because we have JUCE.


Luke was interviewed by Sudara, who is building an additive synth and writes about audio dev over at melatonin.dev.

Have comments on this interview? Ideas for who we should talk to next? Let us know on the JUCE forum

More "Made With JUCE"

linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram