Linux Audio Plugin Development (LAPD)
DDMF
Linux Audio developer interview with Christian Siedschlag from DDMF
This interview was conducted by Amadeus Paulussen in 2025.
Dear Christian, thanks for taking the time to talk about Linux with me. ☺️
I have vivid memories from my macOS times, using the ERS 250 and the MagicDeathEye and being able to restart using them on Linux makes me go through the roof. 😜
How come you are now supporting the growing Linux Audio platform as well?
Well, you certainly played a role in it! It was mainly a not massive but constant influx of people asking for it, plus some exchange I had with fellow developers who gave me an idea of the potential new user base. Plus, the fact that I have been using the JUCE framework since the very beginning which doesn't make it too difficult to build Linux versions once you have a plugin ready for one of the other platforms.
Can you briefly introduce yourself and tell us how you came to develop audio software/plugins with your company DDMF?
My name is Christian Siedschlag. I have a background in physics and academia but wasn't all that thrilled anymore with the long-term prospects in that field. Since I have always been very interested in making and producing music too, I figured I could try out programming software plugins, bringing those two worlds together in a sense.
It wasn't meant to become a full-time thing back when I released my first plugin (the [linear phase EQ LP10) in 2006, but the revenue kept growing, so in 2011 I made the decision to leave academia behind for good and go all in with DDMF.
During the first few years, development was done in Amsterdam, but I moved back to my hometown, Freiburg, in southwest Germany, back in 2012, and have been operating from there since.
Do you make music yourself, and do you use your plugins in your productions?
I used to be in bands and stuff when I was younger; these days I'm mainly trying to keep my guitar-playing abilities somewhat alive. I do have a huge amount of 1- or 2-minute ideas that I have recorded over the years, though, basically whenever something comes up during improvisation that I'd like to keep. With these snippets I also use my plugins, of course. It's not that I polish everything to perfection, and I doubt I will ever really release any of this, but it is a good exercise and a playing field for me to switch the perspective from a plugin developer to an actual user.
What would you say are the biggest challenges when developing plugins in general?
I think, as with many things in life, the last 10 percent are the hardest.
It's not terribly difficult to program a basic EQ or compressor, but to really create a plugin that gives a customer the feeling of Yay, I want this, I can benefit from this... that takes a lot of iterations, polishing the user interface, and making sure to hit the sweet spot of how much complexity you want to expose and give the user control over.
And you have to accept that not every of your plugins will become an instant hit; with some it will take some time, and some you may even have to abandon after a while in order to free up more time for the others.
Then there's also the marketing aspect. The competition is huge; we've had a huge influx of capital investors in the market over the last few years too who try to purchase smaller companies and milk them with endless sales before they move on...
Now we have new challenges with AI, which probably lowers the barrier of entry for new plugin developers (but which will also lead to some really bad products, I'm sure...).
So the challenges are there, but overall it's been a rewarding experience so far.
Are there platform-specific challenges when developing for Linux, macOS, or Windows?
On macOS there have been two complete changes of the underlying hardware in the last 20 years; one was going from PowerPC to Intel and now to Apple Silicon.
Both on Mac and on Windows, the amount of hoops you have to jump through in order to be able to run your code on the latest OS versions have increased over the years (basically, various amounts of code signing requirements).
On Linux, all this plays less of a role, but on the other hand, you have a way more diverse environment with all the different distributions.
What does your development workflow look like (team setup, tools, frameworks)?
DDMF is really just a one-man band, so the team setup is pretty simple. The exception was/is, of course, the development of the MagicDeathEye plugins, which I did together with Ian Sefchick who had developed the hardware. That was a bit more complex, with sending hardware units back and forth and polishing the audio algorithm in a constant feedback loop between Germany and the U.S. until we both were happy.
In terms of tools and hardware, I mainly use two Mac Minis (Silicon and Intel, the latter with Windows on Bootcamp and both with Linux in VirtualBox) so I program in XCode most of the time, testing everything in Plugindoctor.
I create the graphics in GIMP (or I sometimes hire a freelancer for graphic design).
Do you use a framework like JUCE to develop your plugins?
Yes, I use JUCE all the time. It's just the easiest way to be able to release cross-platform audio plugins. What Jules has created is really remarkable. It's kind of sad that he is no longer on board, but the remaining team is doing its best to keep the ship running, and with the occasional hiccup, it's still the perfect framework for me.
I know some companies have rolled their own cross-platform solution, but for me as a single developer, I would have lost so much time doing that I doubt I would have released more than one or two plugins in the process.
What would you recommend to someone already having a Windows and/or macOS plugin and wanting to start supporting Linux?
Well, if you are already using a cross-platform framework like JUCE, it's not all that complicated. Of course you should have a good understanding of Linux in general (which I was lucky to have from my time in academia; back in the 90s when I started programming at university, all computers were running on Linux, and I had Linux on my home PC for some years before switching to Windows for compatibility reasons). Maybe not the smartest move I've ever made. :-))
But even if you've never worked with Linux before, the modern distributions make it comparatively easy to get started. If you take something like Ubuntu you can almost work with it out of the box, install Reaper or something, build your plugin, and see how it goes. If you've already been working on macOS, you probably know most of the Linux terminal commands already, so that definitely helps. The good thing is that most Linux users are still technically more savvy, so you will have fewer support requests than you might fear.
How do you deal with standing out in today’s crowded plugin market?
It's not easy, of course. Fortunately, I've been around since 2006, so while there are, shockingly, still some people who have never heard of DDMF, I do have a loyal user base of people who know from experience that DDMF builds quality stuff and who are open to new products and willing to spread the word online or among their friends.
Then, it helps to have some products in the lineup that are relatively unique (Plugindoctor especially, but also Metaplugin and the MagicDeathEye stuff) that work as door openers for the rest of the bunch.
What do you think are the most important factors for success as a plugin vendor today?
To start in 2025 is tough, I guess. There is definitely a race to the bottom in some corners of the plugin market, and you have to resist the urge to join in. You need a good idea, of course, flawless execution, and the patience and optimistic attitude to believe in success ultimately coming your way.
It is rather unlikely to create a hit plugin with your first release (it happens, but it is rare), so take note of everything you learn during your first release, and give it another go. If you are good, people will eventually notice.
Are you crafting your plugins from A to Z by yourself, or are there other people involved in the process?
Apart from the MagicDeathEye plugins, as mentioned above, I do all the conceptual and programming work. I do hire freelancers every now and then for the user interfaces, but the layout decisions are done by me.
Do you think plugin aesthetics and ergonomics influence adoption as much as sound quality?
Sure, workflow is very important, and the aesthetic feel of the plugin plays a big role too. I sometimes wish it wasn't such a strong contributing factor, but that's just the way it is. Even if most customers are more auditory than visual persons, most also have at least some sort of artistic streak which comes with a feel for the overall aesthetics of a product.
Are there aspects of your products you are particularly proud of from a design perspective?
I like the mouse interface of Comprezzore in which you can click together any custom compressor transfer curve... It looks simple, but it was not easy to get everything right. Purely in terms of graphics design, I like what the Ukrainian graphics company UIMother has come up with for GrandEQ... it's a love-or-hate thing for many people, especially those who are more used to working with EQs that work with direct mouse-graph interaction, but I like the overall look and feel of it.
Do you think Open Source and donation-based models can be a sustainable way to make a living from developing audio plugins?
Interestingly, during the very early years of DDMF, I did use a pay-what-you-want model for a while. I think I was one of the first in that field back then, so it created quite a bit of a marketing effect, and in that sense it was successful in getting the word out.
The range of payments showed a huge variation, from $1 (the minimum) to the occasional $50, and on average it was a bit below $10, if I remember correctly. That was in the phase when I still had a day job, though, so money would have been very tight without that.
It also depends on where you are located, of course (which goes for any pricing model).
I have no experience with open sourcing any of my work. I think that would only work if there was some sort of consulting money to be made from it, which is not very likely for plugins... or in the case of a whole library like JUCE, where other people have the option to release derived Open Source work or pay a fee to build closed source products.
Do customer support requests take up a significant part of your resources?
It's not that bad, actually... Most of the recurring questions end up in the FAQ on the website, and people actually seem to read it. :-)
Do you plan to support CLAP in the future?
I still haven't decided on that. I will not put in a lot of work (unless CLAP destroys all other plugin formats, of course, but currently I do not see that happening); if JUCE contains a reliable CLAP wrapper, which I think it does not yet do officially, I could imagine releasing CLAP versions at some point.
What are your thoughts on copy protection mechanisms in relation to audio plugins?
Nobody has any reliable data on whether copy protection and, on the other side, piracy have a significant economic impact. I sometimes think I see an effect when a crack is released, but then with the next crack, I don't see an effect at all.
It is still an interesting battle, and to be honest, I have enjoyed writing some parts of the copy protection that I now use. Eventually it all has been cracked, but it definitely took a while for the latest releases.
I do have the feeling that there are maybe fewer cracking teams around than 10 or 15 years ago. And it is generally getting harder for them with all the code signing requirements, especially on Mac.
What are your thoughts on subscription-based plugin offerings?
As a customer, I do not really like subscriptions, which is why I have not yet offered that as an option for DDMF plugins. If I ever do it (and I have the impression that it might not be an entirely dumb decision business-wise), I would definitely always keep the option to purchase a perpetual license.
It would also only make sense for the full bundle of plugins, which currently sells for a few hundred dollars, and where you could make the argument that a lot of people (especially from poorer regions of the world) cannot afford to pay that directly but would be interested in paying a small monthly amount instead, with the option to cancel that once they no longer feel the need to use the plugins.
What would you like to see improved in the Linux (or general) audio ecosystem?
I think the options we all currently have on any computer, regardless of the operating system, are simply amazing.
The main problem is choice paralysis from the sheer number of software instruments and effects that we have available. Truly anybody can create a hit record on a midrange computer with a somewhat decent audio interface these days, and that is really remarkable.
Now, as with anything Linux, it takes a bit more configuration and experimenting to achieve, e.g., audio latencies of a few milliseconds, compared to Windows or Mac, where the potential for user error has become really small. But it's entirely possible.
I can only hope that people will continue to use these opportunities and come up with new and fresh ideas for electronic music creation and production instead of simply hitting up Suno and the like with a two-sentence prompt. ;-)