Linux Audio Plugin Development (LAPD)
ACMT — Applied Computer Music Technologies
Linux Audio developer interview with Mike Start from ACMT — Applied Computer Music Technologies
This interview was conducted by Amadeus Paulussen in 2025.
Dear Mike, I didn't know that you were one of the first commercial vendors to develop plugins specifically for Linux. Can you please briefly introduce yourself and your journey through the audio plugin development world so far?
Hi, so, I'm Mike, I'm the owner, and senior software developer at my company Applied Computer Music Technologies Ltd. Before founding my own company I was a design engineer with one of the world's best known recording console manufacturers where I was privileged to work with, in my opinion, some of the best people in the industry. My audio career began back before affordable DSP was a thing — I always had an interest in electronics, and I grew up at a time when 8-bit home computers were just becoming available.
I learned coding first by writing games in 8-bit assembler language (fun fact, I still have a 'side hustle' making modern retro games for vintage computers over at https://www.acmtretro.co.uk/.
I'm also a guitar player, so back in the day I built my own valve / tube amplifiers and effects pedals (way before the explosion in 'boutique' pedal companies we have now). After becoming interested in using Linux for audio production, but frustrated by the lack of available plugins, I decided to make some of my own (I mean with a background in pro-audio, analogue electronics, and software development, how hard can it be... right...? Perhaps we'll come back to that later...)
In the 16 years that you have been developing plugins, how has the situation regarding music production on Linux changed from your perspective?
Linux for audio has improved massively in that time. When I first became interested in using it for audio production there was very little choice when it came to DAWs. Ardour was just about the only sensible choice for the kind of DAW I was used to on Windows, and there were very few available plugins — which is actually what motivated me to develop some of my own. (I also developed the initial native Linux VST2 support for Ardour — and — though VST2 may not have been the most popular with open source devotees, from a pragmatic standpoint I reasoned that JUCE was being used by a lot of developers to make VST plugins, and it had Linux support built- in, so if the most popular DAW on Linux supported VST2 it would be about as painless as it — could — be for many other developers to port their plugins to Linux. More plugins might improve the popularity of Linux for audio, and that might create a kind of virtuous circle).
We're not there yet, but thanks to the incredible work by everyone involved with Linux audio, independent developers, open source projects, and / or commercial companies, there are significantly more tools available, be it DAWs of different kinds, plugins, virtual instruments, audio hardware etc. It used to require a lot of fine tuning to configure a Linux PC for audio, but now you can just install e.g. a stock Ubuntu or similar distribution, plug in a class compliant USB interface, and get performance which is at least as good as — lets say — ‘other’ PC operating systems. Sure you can make more tweaks if you want to, but most importantly, you no longer have to.
What would you say are the biggest pain points when developing plugins in general?
Firstly — and you might not like this — (new) plugin formats. Most plugin formats are similar enough that they don't provide significant advantages, but different enough that they require a separate codebase and maintenance. Certain core things can be portable if they are well designed, such as UI toolkits and DSP libraries, but each format has its own quirks.
Multiply that by the number of host applications, operating systems, different formats they may or may not support, and implementation differences (both on the plugin and the host side) and — as an independent developer — it can soon reach a kind of 'critical mass' just maintaining your existing catalogue against operating system and host application updates with very little time for new things. If a new plugin format comes along, then you have to support it, because otherwise customers may be reluctant to buy the existing ones even if they don't need the new one yet. Generally you can't charge extra for a new format either, so often it means months of unpaid work just to get back to where you started.
Secondly GUIs. Developing Graphical User Interfaces requires significant, and often specialised resources, both at a technical level — the code required just to get the pixels onto the screen — and an aesthetic level. e.g. making something which (hopefully) looks nice, encourages user engagement, doesn't obstruct the creative process and reflects the quality of the product generally. Often it's the first point of contact with the plugin, from seeing its picture on a website to opening it in your DAW. You often have a visual impression of the plugin way before you hear it.
And what are the biggest pain points in relation to developing plugins for Linux specifically?
All of the above, plus GUIs. Did I mention GUIs... One of the biggest challenges on Linux is that there is no 'standard' UI toolkit as such.
So, for example on Windows, you have a set of operating system provided Windows, widgets etc. and a standard API to interact with them. You have a standard file selector, or a dialogue box, and a standard Window 'primitive' (HWND) for example.
On Linux... well, it depends. If you use GNOME / GTK etc. then all of that is provided by the GNOME / GTK toolkit. If you use Qt (KDE etc.) then its all a bit different, and provided by Qt instead. So if you're writing an application, you pick which one you want, fine. But, if you're writing a plugin, you won’t know what the host application may be using and generally you can't run GTK windows / widgets etc. inside a Qt application and vice-versa. Nor should you want to. Fortunately, on Linux X11 provides the kind of low-level single common standard which we need, or at least it did, but now we have Wayland to contend with as well — but that's a whole other discussion...
So at present, a Linux host application will expect the plugin to render into an Xwindow, regardless of its own graphical framework. But X11 / XLib doesn't provide any of those nice things like dialogue boxes, file selectors etc. It’s 'just' a Windowing system. If you need a file selector, write it yourself. If you need a dialogue box, or a text entry, write it yourself. If you need nice font rendering, do it yourself, etc. Which is one reason many developers opt for third-party plugin frameworks such as JUCE.
We use our own framework which means we have to deal with all of that pain ourselves, but we can be relatively agile in fixing any issues which may occur.
A third-party framework frees the plugin developer from a lot of those distractions, but it can mean waiting on an update or patch to the framework to solve an issue for a customer.
Can you tell us anything about the decision around not offering your plugins for macOS?
There was never a decision not to support macOS — when we created our current range of plugins, we made the (bold) decision that they would be specifically for Linux. We hoped that providing professional quality processing in industry standard formats would demonstrate that Linux was a viable option for industry professionals (or aspiring professionals).
However, there can be significant inertia in the creative industry, and while the plugins have proved popular, it became apparent that many prospective users were coming from other PC based platforms. By providing Windows versions too, we hope to make that transition easier. (While native Linux plugins are the best option, there are some bridging applications available which enable a user's existing Windows plugins to run on Linux too, however as far as I know no such equivalent exists for macOS plugins). Developing for macOS relies on some Apple-specific frameworks (Objective C, Swift, etc) so the code isn't as portable, and the frequent hardware updates can impact the development costs, so there wasn't really an incentive to offer them. That's not to say we won't do so in future, but at the present time its not our primary concern.
What was your original motivation to support Linux as a platform for music production?
I'm a Linux user myself. Unix-like systems have traditionally been the choice for high-end applications (CAD, Video and 3D rendering etc.), so why not audio?
Linux provides great integration with all the tech infrastructure required for pro-audio production too, all the networking, servers, backup and storage etc. that no-one wants to think about, but which you really need to if you're running a modern digital audio production facility.
As I think I mentioned before, I found the lack of plugins disappointing, so I decided to make the ones I wanted to use. It turned out that other people liked them too, and so I decided to release them commercially.
Can you tell us what the Linux to Windows ratio in terms of user base for your plugins looks like today?
I can't be specific about that — and we're probably not a typical case, because our range of plugins was developed initially for Linux specifically. Windows support came a bit later (which is kind of the exact opposite of most companies I guess). So our userbase was skewed towards Linux.
What I can say is that anecdotally there were a surprising number of Windows users who were interested in exploring Linux. Even if Linux is not their primary OS, its very cost effective to repurpose an older studio PC as a dedicated workstation for mixing and mastering for example.
What recommendations would you make to vendors who would like to offer their plugins for Linux as well?
Go for it. If you're using a framework such as JUCE, most of what you need is already there, and target a popular mainstream distribution such as an Ubuntu LTS. It normally makes sense not to target the 'cutting edge' — hence an LTS as it tends to be more stable.
In your opinion, are there any reasons not to support a platform (Linux, macOS, Windows, iOS/iPadOS, Android, etc.)?
On a technical level, no not really. I use Linux, but I develop on whichever platform is necessary.
As developers we're in the business of making what we need from what we can get.
Most of the choices are going to be dictated by target market, installed userbase, and / or other commercial factors.
What do you think will be the next big thing in audio plugin development (e.g., GPU Audio)?
I guess you're hoping I'll say 'AI' or something... I mean I expect we'll see more of that in audio generally, but for plugins, I don't know what the next thing will be. GPU audio has been talked about many times, but I'm not sure. GPUs have found unexpected uses, and for certain audio applications if latency is not critical and parallelism can be exploited, they may provide an advantage. From a technical perspective, anyone who has had to deal with the living hell of supporting (all the different) GPUs for their intended purpose, with (often ever so slightly) incompatible OpenGL and GLSL implementations, will likely hope this experience is not repeated for audio.
Do you think we need an initiative like LAPD to better the situation with hardware support (audio interface, specialized tools like monitor/headphone/room calibration hardware/software, etc.) on Linux?
The situation with hardware support has much improved in recent times. Most class compliant USB devices will 'just work' — however there is still a tendency for some manufacturers to use custom software for control functions, and that can be problematic. (Or, everything requires an App these days...).
I don't know if there is a magical solution to this situation (ironically, if I remember correctly, there was a significant rise in the adoption of class compliant USB support due to the perceived need for compatibility with Apple's 'i' devices. So better cross-platform compatibility came from supporting a company often known for being very proprietary — which I guess proves you never can tell what will happen).
From a technical perspective I have always preferred devices which provide a web interface for configuration, so you can just open a browser on whatever OS you have. I guess the ideal would be greater adoption of (open) networked / IP based audio standards and devices which export web based configuration UIs.
What are your thoughts on realistic, three-dimensional user interfaces?
With our latest range of plugins we deliberately went for a more stylized look. Personally I think this integrates better with some of the more modern UIs on popular DAWs. Photo-realistic skeuomorphism has largely disappeared in almost every other user interface apart from plugins — and I see no reason why we can't retain the important visual cues which allow you to navigate e.g. an emulation of familiar audio hardware — but it doesn't necessarily need to have flaky paint or a rusty front panel to sound 'vintage'
How important do you think the design of plugins is?
Just the GUI design or the DSP as well? I think the GUI is important — its the user's first point of contact with the plugin — you see a picture of it on a website before you even decide to download it.
You see it when you first open the plugin in the DAW, long before you hear what it can do. It shouldn't get in the way of the creative process, and you shouldn't have to break out of that mindset to go and figure out which obscure menu option you need.
That goes for how a plugin sounds too, you shouldn't be able to make it sound bad. If I turn a control and its not what I intended, perhaps I'll discover something new by accident, but just like the best analogue gear, it shouldn't do anything horrible.
Often the details we spend the most time on are things that would only be noticed if they weren't there. For example, smoothed interpolated controls with no 'zipper' noise, just like analogue hardware. And users sometimes say 'but I thought everything worked like that' — until you show them a plugin that doesn't. (Tone check your plugins while moving the level or gain controls). Or de-cramped filters which give a more analogue response. Why — wouldn't — it be like that?
And how would you rate the user experience (ergonomics, ease of use, etc.)? In your plugins, for example, the reaction of potentiometers can be adjusted, which I, personally, find excellent.
That can be very subjective — I can only say what I look for in the tools which I use, as a user. I think everything should be as simple as it can be. I actually don't like to have hundreds of configuration options, I find them a distraction (actually I was opposed to having those different control options initially, but I'm pleased you like them).
If I buy a good quality product I want to think that I'm paying for someone to use their experience to make all those design choices for me, and give me the best result.
To take an example, as a guitar player I wasted a ridiculous amount of time with microphone placement trying to capture the sound I wanted from the amp cabinet. With the benefit of digital emulations, I get to do it again — this time with virtual microphones of every possible type in every conceivable orientation. This is very clever, but I just want someone to give me the three configurations that are actually useful.
Do you think that making audio plugins open source and getting paid by donations can be a viable business model?
For plugins, personally, no. The very first plugins I made were donationware (just to cover the cost of publishing them). Most people who used them seemed to like them but I made no money.
Perhaps I was unlucky but in my experience if you put a finished product up on a website, free to download anonymously, and a donation button — most of us know we probably should donate — but often we tend to think "maybe I'll do that later..." (I used to tell myself that 50% of people didn't donate because they thought everyone else already had, so they didn't need to, while the other 50% didn't donate because they thought nobody else had, so why should they).
Empirically the most successful donationware projects seem to be those that are (continually) in development. It works well enough to be usable, but, it's — just — not quite done yet, so maybe if I donate it will be better... Also people's income levels and circumstances vary enormously so perhaps a 'pay what you want / can', option is more viable.
From a business point of view, what do you think are the most important things to get right as an audio plugin vendor in today's crowded market?
(I wish I knew…) Its certainly a more crowded space than it was a few years back, so it can be very difficult to be heard above the noise, but I would say listen to your customers — they afford us the privilege of doing this for a living after all. Avoid unnecessary gimmicks or absurd marketing hype and just focus on getting the core functionality right. Beyond that there's always going to be some luck involved too, as there is with most things.
Do you think it is utopian to think of "competing" developers helping each other out with issues they encounter when developing or porting existing plugins for Linux?
No, and in theory I see no reason why not. There is already an active plugin developer presence on forums such as KVR, so I think a lot of independent developers realise the value of sharing a certain amount of common knowledge when it comes to plugin development generally.
Can you share with us any of the plans you have with ACMT for the future?
We're just going to keep on doing what we do. I have a few ideas I would like to research more but we'll likely just be evolving the product range we already have as well.
Are you looking at plugins from other vendors, and if so, can you tell us 3 of your current favorites?
There are some great plugins available, almost too many to mention. I do try to keep up with developments, though unfortunately I often just don't have the time.
When I get the opportunity to do some audio production, I confess I mostly stick with my own plugins as I’m probably most familiar with them.