Linux Audio Development (LAD)
baconpaul (Paul Walker)
Linux Audio developer interview with baconpaul (Paul Walker)
This interview was conducted by Amadeus Paulussen in 2025.
Dear Paul, thank you very much for taking the time to do this interview!
First of all, I would like to patch a cable between you and one of the most popular Open Source synthesizers, Surge XT. Could you briefly explain who you are, where you come from, and how you came to play a leading role within The Surge Synth Team's development efforts? 😎
I have always been a musician and a programmer. I wrote a program and played a synth before Van Halen released Jump!
In my personal life, I found myself with more time to dedicate to hobbies in 2018.
Around the same time, Claes Johansen (who is one of the principals at Bitwig) decided to Open Source rather than abandon Surge, a popular commercial synth he had written from 2005-2015 or so.
So, I tried to get it compiling! And it didn't compile on my Mac. So I ignored it, but then a few months later came back to see if that had been fixed. And it hadn't. So, I figured out at least the Mac-broken bits and sent in a big PR to get it at least compiling on Mac.
Claes merged it, and made me a maintainer!
But there were a group of us working on the synth at the time, and so we had the concrete idea that we should form a team, which was open-contribution, fun, and nice. That idea stuck, and so here we are today, with one of the more popular bits of Open Source music software written and supported entirely by a group of volunteers in a pretty unstructured collective.
Which of The Surge Synth Team's projects are you currently working on? As I've seen, you're not just working on Surge XT, but also on a follow-up project to the popular OB-Xd from 2DaT and DiscoDSP, which you call OB-Xf.
Surge and Surge for VCV Rack are the two most well known projects, but we've been doing a bunch in the team.
ShortCircuit XT is a pretty well developed sampler. I thought we'd have it in beta for Jan 1, 26, but looks like we may be a few weeks late. It's in good shape and fun to use.
OB-Xf is indeed a sort of revamp of the Open Source OB-Xd synth, with some additions, some subtractions, and so forth.
A few years ago, the maintainer of Stochas, a sequencer, joined forces with us, and we host and build and support that out of the team. Similarly, the Monoplugs plugins B-Step and Monique are part of our family of projects we've helped with, as their author decided to contribute them to the Open Source world, and are now hosted in the team infrastructure.
A large effort we've undertaken is to make our code more library based. Things like our filters are available as header only libraries, available for other Open Source devs. Our tuning library, which goes from SCL/KBM to frequency tables, is quite widely used in both open and closed source contexts. Part of moving from Just-Surge to lots of things involves that factoring.
Are you involved in any other projects besides your work with The Surge Synth Team?
Sure. In the audio space, I'm a reviewer and contributor to the CLAP project and have been since before CLAP 1.0. As well as reviewing and contributing to the core APIs, I also wrote one of the first example plugins, the clap-info tool, and collaborated on the clap-wrapper, which projects CLAP into VST3, AUv2, and a standalone.
I've also collaborated with Chris at AirWindows to package his plugins in a single, consolidated plugin. And just kinda chat with other devs about things here and there.
Finally, I sometimes do little "side quest" plugins to test a library or figure out a problem. Of these, probably six sines is the most popular, but two filters is also pretty neat.
Do you make music yourself? If so, can you introduce us to your work with some links, and tell us what DAW and favorite plugins you use?
I do! I've been playing music in various forms since I was a child, including playing in orchestras, bands, and other ensembles, and doing solo performances.
Right now, I'm in a rock band called Leeward. We play around New York and are recording a record now. I play bass with a pretty informal jazz group. I also do a variety of solo compositions, some of which are on my SoundCloud.
I make 100% of my music in Logic Pro. As well as Surge and the Logic built ins, plugins I rely on in almost every track are Modartt Pianoteq and the Valhalla delays and reverbs.
In addition to those, I find I quite often use a few of the Arturia plugins, especially their Jupiter, the Airwindows collection, especially some of the crunchy filters, tape models, and reverbs, the Plogue OPS7 and Dexed (depending on my mood), and sometimes, depending on my piece and the mix, might reach for an 1176 emulation or some such.
This is a very Mac and closed source centric answer, I realize. My music making is on my Mac. But I've been using Linux for decades in non-music contexts and am thrilled to see that, if something were to make macOS non tenable, I would be able to move to Linux for much of my workflow. I'd sure miss all that amazing audio editing and built in plugin set in Logic, though.
I am often reminded about how overwhelming the diversity of Linux desktops can be for newcomers at first. In my experience, however, this initial feeling of being overwhelmed (which distribution, which desktop environment or window manager, compositor, audio server, etc., to choose) turns out to be one of the core advantages of Linux after a while. Because you can actually put together your own Linux, just the way you want it. This is something that is not possible to the same extent with Windows or macOS, for example. As great as all this is, the modularity and different moving parts of Linux Desktop and Linux Audio also present challenges, such as in the case of the different combinations between X11, Wayland, and Xwayland, DE/WM, DAWs, and plugins. Although, in most cases, users hardly notice this complexity because of automatically acting compatibility layers, I would be interested to hear your view on this specific issue from a developer's perspective.
I'm not entirely sure I agree that this diversity benefits users, or at least, benefits user adoption. But that's not your question!
From a developer's perspective, this diversity can make it tricky to support a uniform experience for your users with your product and makes development tricky, especially if you have to ship binaries as opposed to source.
I've sometimes summarized this for other developers approaching the platform as "Linux Doesn't Exist". (A more accurate statement, of course, is "Linux is a kernel, and the desktop thing people use is a bundle of software with Linux at the bottom"). Some of the built in things you can expect to be uniform and documented in more delineated systems like macOS and Windows are not part of the uniform Linux experience.
Consider the simple act of showing an "open file" dialog. On Windows and macOS, this is a built in dialog in the OS and something which is consistent across properties and user experience. On Linux there's several ways, you have to fork/popen a process, if the DAW has changed the LD_LIBRARY environment, it may not work anyway, etc…. Or, think about the problem with libc versioning, which macOS and Windows have solved in very different ways than Linux. The frameworks like JUCE mask big chunks of this complexity for you, though.
So, if you set out to be closed source and support every flavor of Linux in a way which satisfied all users on all distros, I think you'd probably fail, especially as a newcomer.
De facto, for binary distributions, you can just build with Ubuntu 20 and tell your users how your built your software works, though, and it gets most folks there. It's not an insurmountable problem. But it is a big difference.
Of course, Surge is Open Source, so if someone doesn't like our binaries (which build with Ubuntu 20), they can fix it themselves with a compiler.
As you know, with the Linux Audio Development Initiative, I am trying to get vendors excited about music production on Linux and motivate them to offer native Linux builds of their audio software and plugins. And the longer I do this, the more I become aware of different areas in need of improvement that I haven't addressed yet. Drivers and software for audio interfaces are one such topic, as is software for more niche things, like room calibration or software for controlling external devices, such as mixing consoles, etc. I am already working behind the scenes to cover all these areas in the future, by improving the structure and functionality of the website. I am also working on making my initiative actually Open Source, so that others can contribute to it. I am thinking of providing blueprints for musicians, you know, setups that actually work. And also to portrait music that has been made with Linux. All of this is, of course, a lot of work and will take some time to be completed. What I wanted to ask you is: What would you recommend me to do from your point of view? Do you perhaps have any tips for me? 🙃
I think my first tip is to realize that there are parts of the music production lifecycle which you can't do on Linux, and so users should view Linux music production as part of, but not the be all and end all of, the process.
The state of software on Linux now is that it's great for some things—for instance, Bitwig + u-he + Plogue + Surge let you explore most any part of electronic music creation.
But many devices, like the ones you mention—control surfaces and consoles, but also audio interfaces—have vendors who just don't support Linux yet (and maybe never). If those are a part of your workflow, maybe Linux-only isn't the right approach, and Linux-in-the-mix is a better idea.
So, I guess that leads me to the advice of: Identify musician personas and workflows which your project is working to support. And some of them—like mixing in Pro Tools in a US studio, or film scoring with a heavily iLoked toolset aren't going to be things you do on Linux. But others, like making all the stems and arranging them for that mixing session, if you are in a synth based workflow—easily could be.
You know, I’m excited about the growing interest from audio-software vendors in supporting Linux. However, as more companies—each with different motivations—consider supporting Linux, I sometimes wonder: How can we encourage this growth in a way that perhaps transfers some of the Open Source spirit to those vendors. You know, I perceive the audio software (and hardware) market as fiercely competitive, with new companies appearing almost daily—at least some of which seem to prioritize marketing and sales over creativity and the joy of making music. Of course, everyone needs to earn a living, but the Linux Audio world is, at the moment, still comparatively calm, if you know what I mean. It is just, sometimes I wonder whether it’s wise to invite that entire sales storm over to Linux, if you know what I mean. 🫣 What is your perspective on this, if I might ask?
I think there are some great free and Open Source audio tools. I write some, and I use others.
But, if you want closed source devs to support Linux, and they believe that supporting it is economically viable for them, the sales and marketing techniques which work for their company and brand will probably come along.
If I were you, I wouldn't discourage anyone from trying to support the platform and provide tooling to the users, even if you don't like the vibe of their ad campaigns!
A question related to my previous one, which I ask most of the proprietary audio software vendors, is whether they think open sourcing their products could be an alternative for them. I mean, there are plenty of examples where it seems to work. But there are certainly also many where it doesn't. How do you see the dynamic between Open Source and the livelihoods of the humans behind the software?
Open Source for "endpoint" products like Surge is not really very commercially viable, I don't think. People making money selling plugins are better off keeping them closed source if they plan to continue selling them.
Open Source for "library" initiatives makes a lot of sense. JUCE being an open dual license mix, standards like CLAP having proper, non-contagious licenses (and VST3 following that 3 years later), and projects like MTS-ESP with Open Source client attachments have all been part of the success of those efforts.
In between are platform plays, like VCV Rack, where being open has led to a lot of great modules in that system, and where the company can maintain a revenue model with closed source extensions.
Open Source could be a nice off-ramp for abandoned products. That's how we got Surge! But even then, decoupling from vendor or closed source libraries, making sure all your code is properly contracted and owned, and finding someone to actually maintain and care about it is work. And even though "dump it on GitHub and see what happens" worked for Surge, "dump it on GitHub and see what happens" never works.
But I don't think a person selling a plugin on Mac and Windows would be well served in open sourcing it if they plan to continue selling it.
Something else I wanted to ask you: How would you say is the state of accessibility with audio software, and plugins in particular?
Accessibility is an important part of Surge. Surge is, I think, the most usable general purpose synth with screen reader and assistive technology. And this was a lot of work, first by the OS vendors on Mac and Windows, then by the JUCE team to normalize those APIs, and then by us in the Surge team, with a group of users and team members who helped us develop the right approach.
So today, in the music world, Reaper (and soon Live) plus a set of plugins let blind users and other users who deploy assistive technologies make great music on Mac and Windows.
On Linux, the story is less clear. Since there is no API on Linux akin to Cocoa or Win32, the type of coding you need to provide assistive tech ends up in libraries like GTK, (eliding a whole bunch of technical details), which, because of a variety of technical issues and the diversity of Linux desktops, is not something easily available to plugin developers. Accessibility is getting more visibility as desktop usage increases, though, and I suspect this will continue to evolve on Linux.
If someone reading this is an expert on the assistive tech APIs on Linux, though, and they want a testbed in the plugin world, I'd be thrilled to talk to them about ways to collaborate.
My core message to folks looking to support accessibility is to work with users who use screen readers and similar technology day in, day out. As a user of the sighted user interface, you will not get the full experience of using the tools without that collaboration.
What impact do you think Steinberg's recent decision to make the VST3 SDK Open Source will have on the audio plugin sector, and do you think the decision to make it Open Source could be related to the growing popularity of CLAP?
I'm very happy our friends at Steinberg have finally chosen an appropriate license for this important bit of audio infrastructure!
Which frameworks and plugin formats are you familiar with, and what are your favorites, if I may ask?
Most of the dev I do is JUCE and CLAP-plus-clap-wrapper (which has me in the VST3 and AUv2 APIs also). JUCE is great software, the team is collaborative, the community is large, and the functionality is good!
Can you tell us a little bit about your computer setup? Distribution, DE/WM, IDE, etc.?
Sure. My main environment and where I spend 95+% of my time is an M1-Max MacBook Pro with 2TB SSD, 64GB of RAM, and as of this writing, I'm running macOS Sonoma 14.6.1. It's really great hardware. Various places where I work have 4K monitors and Microsoft ergonomic keyboards and Mac Magic Trackpads at them, but I use it as a laptop a lot as well.
For development, I use CLion, which is the first IDE which got me to break my 25+ year Emacs habit. CLion is fantastic.
I do have an Intel box I boot from time to time when I need to check out something on Linux or Windows. It's running Ubuntu 24 LTS with really no tweaks, or Windows 11, dual boot. It's … uhh … whatever you could get in a small desktop footprint from Amazon for 600 bucks in 2022.
Does one of the major desktop systems (Linux, macOS, or Windows) cause The Surge Synth Team more or less effort in terms of development and support?
All computers are bad. Each computer is bad in different ways.
I would say our Linux users are, by and large, the most technical and give us amongst our very best bug reports.
But once we got up and running on each OS, and committed to doing things like building every commit on every OS (which we can do thanks to the generous GitHub Actions provided by Microsoft to the OSS community), the cost of supporting the tools is not really correlated with the OS, it's more correlated with user experience. It's pretty rare to have an OS-specific bug, unless it's related to HDPI on non-macOS systems.
I think this is also our experience because we have developers and users of the project on all platforms most of the time, though. So, if we do somehow break something on Windows and not Mac, we find out pretty darned quick.
What, in your opinion, are the biggest challenges involved in developing audio plugins in general, and are there any particular challenges associated with developing audio plugins for Linux?
Oh, goodness. Well, you have to know so much if you want to deliver a plugin which has any impact.
I mean, let's assume you want to make a bit of software which easily reaches most users. You need to support, at a minimum:
- Windows 10 and 11 with VST3
- macOS 10.15 or later with VST3 and AUv2
- Linux with VST3.
So, even if you can write the innards of a plugin, you need to figure out how to do those builds, get the software signed on macOS, get it packaged on Windows, get your build machine able to make an acceptable build on Linux.
And that's before you even get to any of the DSP, or logic, or infrastructure. Which is moderately difficult real time programming and math.
And once you've done that, you need to test in at least Live, Bitwig, Reaper, S1, Logic, FL, Ardour, and Cubase.
So, really, to get something simple, like a low pass filter plugin with a resonance and cutoff control, running in every environment requires a large span of varied knowledge.
Projects like Pamplejuce can definitely help by providing patterns on top of the frameworks. But it's still work.
And finally, once you've done that, you need to let people know you exist, and you need to support them. So, you have to be in forums and have a Discord or whatever, and so on and so forth.
Gosh. So, that's just a lot of activation energy. You can skip some steps (like, we don't really test in Cubase very often, but we have users who do), and you could choose not to support Linux or macOS or Windows and lose a community. But each of those decisions has an effect on the impact of your plugin.
As to the cost of Linux: Linux adds another build, with associated complexity, adds a few more forums and communities to monitor, and gets you some great bug reports. Of the list above, the incremental work to support Linux is a few percent, as long as you don't make a Linux incompatible choice in your software stack.
What advice can you give to vendors who already offer their plugins for macOS and/or Windows when they are considering whether to support Linux?
If you have a critical dependency on something not on Linux, like iLok, just don't bother.
If you don't, and you have a hand rolled framework, it could be hard, but it could be fun.
But, if you don't have a critical dependency on a missing library, and you use a popular framework like JUCE, supporting Linux is easy, people will buy and use your plugins, and the community is mostly nice, and friendly, and competent. Just ask a dev who has already done it.
OK, let's move on to a completely different topic. What is your assessment of AI's future influence on music production (and the development of music production tools) from a bird's eye view, and does AI already play a role in your work today?
I use Junie, the CLion coding assistant powered by a variety of the LLMs (it's kinda like IntelliJ Cursor), and it is fantastic. I'm already using it to increase my productivity.
Generally, technology is disruptive, destructive, and additive all at once. AI is a big technology change. I think there's a lot of music production work which could be displaced (like jingles for commercials), but I also believe that making music is a fundamental part of being human, so the experience of grabbing a guitar and a drum and a bottle of wine and playing music with friends will never go away.
So, who knows. But we will probably get some useful stuff, some disruptive stuff, some hideous slop, and some awesome stuff. Just like we did when we got recorded music. Or amplified music.
Outside of the music industry, the situation is more complicated. I don't want to dismiss those issues, but don't feel like this is the forum, or I am the person, to address them.
Would you like to add anything else?
Yeah, this interview is with me, but the Surge effort really is a team effort. We have north of 50 contributors to the main repo, and loads of team members who work on design and documentation and support outside of the C++ code. It's a fun group to be part of! And we always welcome folks!