Linux Audio Development (LAD)
Audio Damage
Linux Audio developer interview with Chris Randall from Audio Damage
This interview was conducted by Amadeus Paulussen in 2025.
Thank you very much, not only for participating in this interview but also for being part of a cool bunch of Linux Audio pioneers. How long have you been supporting Linux, and what motivated you to offer your plugins for more than just macOS and Windows?
I believe we shipped our first Linux build in 2015 or thereabouts? Our habit when adopting a new platform is to ship our free plugins first, in this case our Rough Rider compressor. Then we use the feedback we get from that to figure out how to add it in to our workflow. As for why, I'll build for anything that has a reasonable audience. I enjoy figuring out the build tools and it's not really much trouble otherwise. Our code is extremely portable for the most part.
What is it like to work at Audio Damage? How big is your company? Do you work from a shared office or from "anywhere in the world"? Please tell us a bit about Audio Damage.
We are and have always been a two-person company. We're happy with that. We occasionally have contractors or physical help when things get demanding (especially pre Covid when we were shipping physical modular synth modules and attending trade shows), but we generally conspire to keep the company from growing any more than we can handle in a couple hours a day. I work from a spare bedroom in my home in Vermont, and Adam does the same from his home in Colorado. I can actually count on one hand the number of times we've met in person in 23 years. We have always been remote.
Some of your plugins are quite complex. Do you have to take platform/standard-specific things into account in terms of performance, e.g., for UI rendering, or are such things perhaps handled by a framework like JUCE?
We use JUCE. If we had to hand-roll wrappers for each of these formats the chances of doing anything but the main macOS and Windows versions is unlikely. There's no "team" to assign to problems like that. One of us (usually me because I hate it the least) has to decide to do it.
Have you ever taken a closer look at GPU Audio? What are your thoughts on it?
Generally speaking, that falls squarely in the Bad Idea category for us. I can only come up with one reason to do it: slightly faster math. But I can easily come up with dozens of reasons not to do it. Principally, though, in order to ship for every platform with relatively little effort (which we don't have to spare) we need to ship a product with lowest-common denominator internals. And that precludes needing a particular GPU.
How do you see the development in the audio plugin market in general, and do you think that Linux Audio could gain in importance?
There are really three markets: first, the standard studio tools one would use for mixing. Then there are the genre-specific tools one uses when making genre music (like, one would "need" Serum because one produces dark dubstep). And the smallest, but most interesting, is the experimental market where we live: people that are hobbyist sound designers and musicians. Most people think "I need to make this sound, what's a tool that can do that?" But these people see something and wonder what they can do with it, coming at it from the other direction. This is the market we cater to. I think the other two will be heavily affected by the sudden appearance of AI, but ours won't, since there is generally no prior art. Linux people tend to be that last group, by and large, so I don't know about "gain," but it will certainly remain stable and viable.
What are your experiences with the users of the different operating system platforms? Is it true that Linux users generate more support effort than macOS and Windows customers?
Anyone that thinks Linux users are demanding has never shipped iOS products. We will occasionally get a letter from a Linux user that is not fluent in computertalk, but in general, I find that when I get a bug report from one of our Linux users, it usually has steps to repeat and all the ways the user tried to deal with it, and occasionally it has suggestions for solves. This would be unusual for Windows users, rare for macOS users, and essentially a unicorn for iOS users. Now, that said, the Linux users often assume I have far more knowledge of the platform than I actually do. They'll be all "I tried the floppity build of Bluestain but the resonances were not aligned with version 7.4.7.5.322a of the greeble fork" or whatever and I have to ask ChatGPT what the ever-loving fuck they're going on about. We don't have a person here dedicated solely to Linux, so... We do have people we can ask, though, who are extremely fluent, and we haven't really hit a wall yet.
What does your development stack look like?
Obviously we build JUCE products, so we work in C++ entirely. We use CLion on all three platforms for IDE duties, and CMake for deployment. I have a Python script for creating new products, and then a bash script on macOS, Linux, and iOS, and batch script on Windows, to perform the deployments. Because we ship AAX and can't afford the cloud signing, we have to build on physical hardware for macOS and Windows. For a long time I built the Linux deployment on Windows with WSL, but I went back to a dedicated Ubuntu 22 box just because the other way felt greasy. The iOS version is built during the macOS build script, and deployed using Fastlane, which I love.
Unusually for a smaller company, we've built our own cross-platform installer app, so the build scripts build the plugins, zip them up, and add them to the payload of the installer executable, then they build that, sign it where necessary, and zip it up.
Can you perhaps roughly quantify into which parts the work on a new plugin can be divided for you and what percentages these areas take (I'm thinking of DSP programming, UI, UX, performance optimization, marketing, support, etc.)?
I generally come up with a rough design idea. This will usually just be words; I don't mock anything up. It gets put in the pipeline when I can explain it to Adam well enough that he can agree that it's something we should do. After that, I run our Python script that creates a new product, and rough in some of the parameters and the beginnings of a UI. Then I set it aside while Adam works on the beginnings of the DSP, and creating the parameter set. Once we have the parameter set and the beginnings of ranges of the parameters, it comes back to me and I begin building the UI.
Interesting point here: I do not mock up the UI at all, and our UIs are entirely procedural with the rare exception of logos and such. I actually code them in place. There is no Figma or Illustrator doc or whatever.
Anyhow, we just kind of soldier on, refining the UI and the DSP until it's ready for beta testing. Then once our group of testers has it, we refine it further to the shipping product. Somewhat unusually for a smaller company, our beta testers have a lot of power. If they can convince both Adam and I of a feature that should be included or a major change that needs to be made, we'll do it. Once everyone's happy with it, I build the full deployment scripts and the product page, which takes me an afternoon.
So, I'd say that maybe 60-70% of the work is directly under me, but I have templated and scripted a fair chunk of it, so I actually put in less hours than Adam does on a given product. I do all the marketing and email support once the product ships, and we both do Discord support. We do far less marketing than we should, but it is the least fun part of this entire job.
Are you currently working on new plugins? Can you reveal something?
Yes! We have two in the pipeline, actually. One is the sister plugin of Ascent, which is naturally called "Descent" and which will be out in January. And the other is a synth; we have the engine built, and it sounds great, but I want to do something unique for the UI, so I need a minute to think that out. Look for it in March or April.
Do you sometimes share know-how and ideas with other plugin developers?
For sure. We have a private forum that many (most?) indie devs participate in, as well as a few of the DAW makers. It is very handy, and there are some old, old school plugin devs there who are exceedingly helpful. It has really saved a lot of us from constantly reinventing the wheel.
Does the fact that there are quite a number of DAWs and plugin formats on the market mean extra work for you in terms of dedicated patches on a per DAW and per format basis?
Generally speaking, if it's a DAW- or format-specific thing, we don't do it. This includes operating system specifics.
Can you tell us about two great aspects of audio plugin development and two, maybe, not so great ones?
I've been doing this for 23 years now, and Adam has been doing it longer. The great aspect is that we've made pretty okay livings without having to bust our ass or have any major moral dilemma. The main problem is that everything we do relies on the operating system makers and the DAW makers, and their whims. Dealing with multiple moving targets, as such a small entity with no recourse to speak of, can be irritating.
Finally, if you could change the rules, what would you change to make audio plugin development and the audio plugin landscape better in general?
I mean, "rules" is a strong word. It's music. Nobody's going to jail or the hospital. I personally would like it if private equity fucked entirely off and went and played in someone else's sandbox. In the long run, a single, massive entity doesn't help anyone. I don't think the whole "growth at all costs" mentality is suited for what is, at the end of the day, a creative endeavor. But I'm not greedy, so I guess I'm in the minority.