Linux Audio Plugin Development (LAPD)

Auburn Sounds

Linux Audio developer interview with Guillaume Piolat from Auburn Sounds

This interview was conducted by Amadeus Paulussen in 2025.

Guillaume Piolat from Auburn Sounds

Dear Guillaume, when I switched to Linux in 2020, I discovered your plugins, which I had never heard of in my macOS days. Today I use Couture, Panagement or Inner Pitch in almost every production. How challenging do you think it is to be visible in today's crowded audio plugin market?

Thanks for using our products!

About the visibility question :)

I feel like it is very much challenging to get noticed, of course.
For Panagement 1 in 2016, I copied the model of Tokyo Dawn Records.
High-quality software for free, with a paid option.
It felt smart for a while, but it turns out it's a "mid" idea in the long run.
What seemingly worked instead is bringing new interface designs.

What is your perspective on the choice of operating system for music production?

Walter Bright (D language author) often says that you gotta go where the users are. So we supported Windows, then macOS, then Linux.

Linux support was actually started by Open Source contributors, I didn't want it initially. :)

Can you tell us a bit about the kind of challenge it is to offer plugins for three operating systems and in five different formats (VST3 / VST2 / AAX / AU / LV2)?

Dplug implemented support for VST3, VST2, AAX, AUv2, LV2, FLP and CLAP. That's 7 formats for 3 desktop OS.

Well, the plugin formats themselves aren't really a problem, it's mostly a one-shot cost.

The things that are challenging in a plugin framework are:

Do you plan to support CLAP and do you think it is better or worse than any of the other formats?

Well, we already support CLAP.

CLAP is well-made, and the extensions expose the underlying semantics of the DAW vs. plugin relationship. Implementing CLAP was a pleasure, since you get help and can provide feedback. So… yeah, that makes it a bit better. I have no horse in this race.

Are there platform-specific challenges to overcome when developing audio plugins, or do the platforms share the challenges?

The winning move here is to rely on an existing plugin framework and avoid that work in the first place.

The plugin framework creates the commonality you need to develop the same product, whatever the OS.

Do you use a framework to develop your plugins?

Auburn Sounds developed the Open Source framework Dplug and uses the D programming language for everything. Remade the website last year, check it out. :)

Do you design your unique UIs in-house? How large is your team? Who does what?

Almost everything is done in-house: Dplug framework, code, graphics, and algorithms.

We have used two AirWindows algorithms in Lens and Graillon, and the surprising GammaEnv from Voxengo in Couture.

That's about it for external input.

I'm especially proud of the niche image codecs we use for the interface images: QOIX and SQZ ; they complement our PBR rendering and lower installation size.
I wonder why some vendors keep shipping huge PNGs like that.

As for our organization and specific methods, a lot of it is hidden in plain sight.

Do you make music yourself, and if so, with Linux?

Well, I can make music, but I need an inspiration reason to do that, usually other people or a new plugin release.

And no, I don't personally like Linux.
Linux is lacking in ergonomics; designers need to be given way more power there.

Have you ever considered making your plugins Open Source, and do you think it would be possible to finance the livelihood of a small team that way?

Consider a lot in our plugins is already Open Source through Dplug and the "Dplug Wasteland", a collection of algorithms.

Giving back to the Dplug Wasteland is only natural; other companies have started using Dplug and sharing algorithms and widgets in the Wasteland. It's like a shared dump with no maintenance from anyone.

For our products, I don't think it would be reasonable at all.

Do you collaborate or exchange ideas with other plug-in vendors?

I see commercial developers often exchanging ideas with each other, yes.

You have three wishes (limited to the audio plugin world, I'm sorry); what would you change?

Haha :)

Are you currently working on new plugins? Can you share anything with us?

Like clockwork, you can expect something from Auburn Sounds every year in the autumn.

What do you think the Linux Audio Plugin Development initiative needs to bring about a positive change for the plugin situation on Linux? And what else do you think needs to be improved on Linux to make the platform more attractive for music production?

My opinion is that Linux needs to attract designers and put them in charge. There are too many UX issues everywhere for the Linux Desktop to be mainstream. Every time I boot into Linux, it's frustrating: things on the order of inverted "OK" and "Cancel", crashes, mouse behavior...

Do you think that Linux will gain importance as a platform for music production and that more and more vendors will offer their plugins for Linux?

I don't know. Vendors will probably come since it's good for the business and the platform is rather stable, well, if you use only the C library.

Finally, can you tell us about two nice and two less nice aspects of your workaround plugin development?

Nice:

The bad:

(^) Back to top