Linux Audio Plugin Development (LAPD)
u-he
Linux Audio developer interview with David Schornsheim from u-he
This interview was conducted by Amadeus Paulussen in 2025.
Dear David, thank you for taking the time to answer my questions. <3
When I switched my computer-based activities to Linux in 2019, I was happy that some vendors were already offering Linux builds, and among them was also u-he, one of my all-time favorite plugin vendors. :) How long have you been supporting Linux as a platform?
I actually don't know when exactly we introduced Linux support because that started before I joined u-he.
I know that Alexandre Bique used to freelance for u-he at that time. Maybe it was around 2016, 2018, somewhere there. I guess you can look it up at KVR. There's probably a forum post where Linux support was announced.
And as far as I know, Alexandre Bique basically setup Linux support as part of his freelance work for u-he. And I have been told that the basics took him two weeks, which is pretty fast.
Later, he started working for Bitwig. He's also basically the inventor of the CLAP plugin format.
He actually made it like 10 or 12 years ago. There's a post in the Ableton forum that nobody responded to when he made the first announcement of CLAP being ready and asked if they would like to implement it into Live.
It was kind of funny. Nobody back then cared about it. But it has made quite a turnaround.
And that's about it. Alexandre Bique, the guy who made the CLAP plugin format, was also responsible for the initial Linux support of our plugins.
Okay, interesting! I think I already know the answer to the next question, but I still want to ask you: Why do you still call your Linux plugin builds beta versions?
I don't know, do we call it eternal beta or permanent beta? ;)
We're kind of a small company, and we have maybe six or seven developers. Most of them are not full-time Linux developers.
Each developer is on their native platform; a lot of them are on Mac, and the rest are usually on Windows. And I'm the one who occasionally boots into Linux; looks if everything works.
We also have continuous integration for all three platforms.
The thing is, sometimes we integrate big new features, like, e.g., a new oscillator that works on splines and that needs some spline drawing and a GUI to get it working. And usually something of such a new feature set is not available on Linux right from the start, but we want to get it out quickly into the hands of people to try it out. So, sometimes it can take like one or two weeks until the Linux version of said new feature will be available as well. So it's mostly due to stuff like this.
It's kind of a thing for us to say, okay, we can do the Linux build later. Like, you know, it will be there. It's not like it will be years later. You know, it will be there. Just not when we start the beta or the release, whatever.
Some vendors say they offer Linux builds but only provide limited or no support for Linux. I always assumed that this was simply a way of trying to avoid complex problems where, for instance, someone might buy or download a plugin, use a rare distribution, a fancy window manager, and/or special kernel, and then reports that something doesn't work. From a vendor's perspective, you might just want to be able to say that you cannot support every edge case in the often-perceived 'fragmented landscape' of Linux. Some also say that they only support e.g. Ubuntu.
That's true, but we actually do listen to a lot of feedback from our Linux users. Very often, they also help each other out. That's pretty cool.
It's certainly not that we are just fixing Ubuntu bugs and everything else, we ignore. It's not like that.
But you know, once you get into very specific bugs that only happen on, let's say, NixOS, then you start to be like, well, it's a very, very different distribution. You know, yeah.
I think we always try to see if it works on major distributions, like, you know, the Debian family.
And most of the time, if there's a bug on Ubuntu, it's also on all the other Debian-based distributions.
And then, sometimes, there's something that only happens maybe on an Arch based distribution. But that kind of stuff usually tends to be a one-liner. We usually create the code with the variances that Linux usually has in mind already. Like launching a file picker using xdg.
I think Linux is often perceived as a landscape of vast possibilities. This extends from the bootloader and kernel to the compositor (Wayland vs. X.org, the audio engine (ALSA, PipeWire, JACK, or Pulse Audio) — as well as window managers (Hyprland, Sway, i3 etc.) and desktop environments (GNOME, KDE, Xfce etc.). Initially, I assumed that this would generate a lot of support efforts on the vendor's side. Like Linux users approaching vendors with many scenarios and that vendors would be unable to support them at all because they would have to replicate their setups in the first place. However, many vendors have told me that this is not actually a real-world issue for them. Apparently, Linux users try to help themselves first and only create support tickets as a last resort, and these often contain a high level of relevant details. The bottom line is, and here it comes, most of the vendors I spoke with said that macOS is actually the most support-intensive platform. And so I wanted to ask you what your experience of providing support for the various operating systems looks like.
It is not false to say that macOS usually requires some maintenance. It normally happens every year that you need to make some adjustments.
Obviously, when Apple is changing the CPU architecture, then that maintenance is like a lot of work. Especially if you are doing all the vector optimizations by hand as we do, which gives you an edge in some situations.
But I would say that in the last two to three years, it was actually less effort on macOS than usually.
The funny thing is, my next question is, I guess, a little similar to the situation on macOS where Apple just dictates something, and then you have to kind of adapt. Like, on Linux, some developers don't like, for instance, the success of Flatpak because it makes so many things impossible that were previously possible. Things like inter-plugin communication. And it also creates new problems and limitations. But then, from the Linux Desktop User Bubble perspective, I think, e.g., PipeWire is absolutely great. Wayland too, and I also like Flatpak a lot. But, again, I think from a developer's perspective, some of these new technologies might actually first and foremost pose challenges. So I wanted to ask you what you think about all of this new stuff on Linux?
So first, PipeWire, I think is awesome, love it. I can make connections from one program to another—stuff that was previously only possible with JACK. Now that's possible with everything, you know; it can go from Pulse Audio into Reaper with different samplerates and stuff like this. That's so cool.
There was a time, I think it was before the 1.0 release, where PipeWire didn't work really well with those IRQ-based ALSA drivers. You know, they always called it old-school ALSA drivers on pipewire's IRC. At that time, I was like, Oh, Jesus, and this is the future? :) But somewhere before the thing turned into version 1.0, they actually did something, and that worked wonders. Really happy to see PipeWire getting used by default in all the desktop distributions these days and it's compatible with Pulse Audio, it's compatible with JACK, it's compatible with anything.
And, if you are just making plugins, you actually don't realize that something like this even exists. You just communicate with the host, and the host does all the interfacing. So as a plugin company, we don't really care that PipeWire exists. Just from my personal experience, I think it's really great.
Then there's Wayland, and, interestingly, we don't have much to do with that. We use X11 and so do all the hosts I know so we're likely running with the XWayland compatibility layer under wayland. So for now, we weren't forced to port our plugins to Wayland. When it was there, it was like everything just continued to work. We didn't have this kind of, oh, now Wayland is coming up, we got to do something. We didn't have that. So that's good. We might want to look into Wayland in the future for things like Clipboard support or Drag and Drop but I have no idea when.
And then there's Flatpak. Well, I think it's obvious that it's not made for plugins. What it does is that it containerizes everything. And when you have an environment where you start your main application, and you're expecting it to load binaries from other places of your system like a plugin directory, that is the complete opposite of what you want with containerization, right? Those two things don't really go together.
I'm not sure if there have been successful initiatives in making plugin architectures possible there. I heard of some ideas and initiatives, but I don't know what they turned out to be, what the current status is. I really have no idea.
From a user's perspective, when I just use Flatpaks, all I can say is that I have more problems with them than I had before using them.
Like, now I usually have to worry about, okay, does it have access rights for this, for that because it never asks you. It just says no to everything. ;)
So now you have to think about access restrictions and get creative and, you know, start trying things out. And it gets worse if you have no idea about where your data lives. There have been distributions that switched some of their native packages to Flatpak packages without migrating the data of the users. So after those updates, you start your mail app and suddenly it looks like all of your data is gone. Such technology transitions can be handled more smoothly. So honestly, as a user, I'm kind of annoyed by it.
From a developer's perspective, I can see why it's necessary. From a plugin developer's perspective, right now it's not what we need. And from a user's perspective, I think it is too early.
I understand what you mean. It's kind of like developed in the open, right? I recently wrote an article about how happy I am with Linux, but that I also have to be honest about the fact that I had to learn a lot. Things like you said, for instance, I like to use both the light mode and dark mode on my system. And I also like to install most of my third-party apps as Flatpaks. And out of the box, some of them just do not respect the system's color mode. They just stay in light mode. It turns out that they usually just need access to the themes folder. Stuff like that. Trivial stuff, but you still have to learn about it and what to do (or not do) to solve it.
Yeah. I tend to make exceptions for simple apps that need frequent updates and store their data in the cloud. For this kind of apps, I think Flatpak makes sense. For the rest, I usually rely on the distribution's packages because they work well enough, you know?
And that, at the moment that makes my life easier.
I guess it's always a bit like that with Linux. Like, if you are on the bleeding edge of technology, stuff can get a bit rough at times. Luckily, we have so many distributions including more stable ones to choose from.
I started with Manjaro because I wanted to have something Arch-based, but did not want to be intimidated by the operating system. ;) But meanwhile, I am on Arch. And sometimes things break. And often you don't immediately notice it. Like the other day when I noticed that all the PipeWire inputs were turned off and could not be turned on all of a sudden. And I thought it was because of a PipeWire package update, but actually, it was because of something I changed. I renamed the PipeWire devices and made a mistake in the configuration file. I guess all I want to say is, when you are living with your operating system on that level, then you have to expect that things break, and that can, of course, be annoying in certain situations, even if it is not the distribution's fault.
Yeah, that's true. So with updates, because I am also on Manjaro, I usually know what's going on. What I do is, I normally wait one or two weeks with updates, then check the Manjaro forum and look like, okay, what do people complain about? Because I would rather not be the first running into a problem. :) And then having to deal with, like Steam not starting anymore or a plugin not working anymore. I just want to get stuff done. Because you don't have a lot of time when you have work and children. You usually just want to be like, hey, click and be done. And maybe one, two command line calls after that to fix some bugs I don't really care about.
Yeah, I think Manjaro is a great option. With these update posts on their forum, they really give you a good idea of what you have to expect. And with Arch, the updates are not only much more frequent. You also actually often have no idea what to expect. ;)
Kind of wild for you to do all your production on Arch. Because the system is so bleeding edge, right?
Yeah, I don't know. It also has to do with the fact that the longer I was on Linux, and the more I was involved also with reporting bugs, asuggesting features, or even contributing stuff, the more I felt connected with my system, and the more I wanted to know about it as well. It made me get in contact with the developers and start interacting with the development cycle.
That's cool.
Yeah, that's actually one of the things I like the most about Open Source. When I think about Apple, for instance, I haven't looked at the Finder in the last two or three versions of macOS, but it had bugs forever that were never fixed. And you could file some bug reports, but you would never even get a reply. So, it's a very different experience when you go to GitLab or GitHub and you open a ticket, and the developers pretty much all the time ask you for more information, or explain to you why a bug actually happens. It feels just much more satisfying to me.
Yeah, that's true. I also used to actively report issues. But at the moment, I guess around when I got my second child, I was more like, okay, can I live with this bug? It's always kind of a trade-off of the time, of the total amount of time that you have and the things that you want to get done with your system. But I absolutely see why this is so cool. You can be in touch with the developers and maybe convince them that something would be useful for their software.
But then there's GNOME where you have the file manager Nautilus starting a search when you type something instead of simply selecting the file. I think it has this ticket and even a merge request implementing that feature and it has the most reactions, like thumbs ups or something by the community. And it's just getting ignored by the developers. It really depends on the kind of system that you are on, I guess.
I guess GNOME is also really on the other side of that spectrum because they have their own ideas, and they historically seem to have been ignoring outside input quite often. ;)
Yeah, exactly. They're very special with their vision and how they integrate user feedback.
So my next question is, because I really love u-he plugins, and I guess, if I would not have those plugins, I would not be full-time on Linux...
That makes me happy to hear.
No, really, your plugins are amazing! So, IMHO, they give the impression that UI and UX play a big role in developing a new product for u-he. I wondered if you could tell us a little bit about the approach you follow when you develop a new product. What comes first, scribbles or ideas, sound, DSP, GUI designs?
So, usually, a lot of the ideas come directly from Urs. He's like our creative director. He has ideas all the time. The problem is catching up with executing the ideas. ;)
His ideas mostly are about DSP concepts. Like, wouldn't it be interesting if you were able to influence this or that? Wouldn't it be more interesting if we were able to twist this around and give users that instead?
It usually starts with that kind of question, and then the u-he team evolves around that.
We often do multiple iterations on ideas. We try this and that and try to find out what we like about this or that.
We would then post results in videos or something, so everyone can comment about the advantages or disadvantages of a certain approach.
If we think it's not really working well, and we try out something new, it evolves organically.
So, we usually start with something abstract around signal processing.
I'm not sure if I've ever seen GUI first, and then DSP or something on top of that. That's not really how we do things.
We first think about what do we want to make and how it could be interesting to people, and then we try to see how we can make it usable.
In that phase, we usually throw out a lot of stuff as well. We might start with 50 parameters, and then we throw them all out until we have 10 left. And then, if everything works out, we say, Hey, this is cool. Now we have fewer controls, but we have this range, and this range is good.
How many people are you currently on the team?
Around 25. Something like this.
It started with one. Right now, for instance, we have two people who are focused on web development and customer database stuff. That used to be all just one guy who was also doing our entire IT, and now work has been split out a bit more.
We have maybe four or five people working on support. Usually, our sound designers also do support because sound designers tend to be very good at using the plugins. They know the products really well, so that makes them naturally very good at helping out others.
When I approach smaller vendors and ask them for Linux support, and it so happens that they actually say, Why not?! They usually end up providing the binaries and sometimes an installer shell script and the thing is ready to be published. When I compare this to the many installer applications I had to deal with in my macOS days, I am so happy that I get to do everything transparently with shell scripts or even manually on Linux. Let's say, for instance, Native Instruments or Softube wanted to come to Linux; they would probably have to develop a Linux-specific installer application as well. However, many Linux musicians told me that they would never install an installation manager application on their system. So, my question to you is: What is your stance on installer applications and the typical Linux user's aversion to things like that?
So, first things first, I think every company is entitled to do whatever they think is best for their customers. Like, if they think that this kind of installation manager is the best thing for the users, then I guess they are the best ones to make that call.
I mean, you can look at some company's portfolio and say they have maybe three or four actively developed products that are updated regularly, and the rest is soundware. Soundware is usually just content with some hundred or thousand presets or patches. And then you sell that usually without maintenance updates, so basically the product is done. That is soundware.
Soundware is a very different kind of product than a synthesizer. So they may have two, three, or four synthesizers, but then they have this giant catalog of soundware.
And then they sell these things in bundles, you know, where you can sometimes, for like less than three hundred dollars, get something close to a terabyte of the soundware. And each of these products has its own individual installer. You would probably have to spend an entire day installing such a catalog manually. So I'd say for such a company, it makes sense to have an installation manager.
For a company like us, however, it's a different story. We work on products for quite some time. We don't update all of our plugins once or twice per month or something like this, you know?
We usually update a plugin maybe every two years or so. It's not that we are not working on it. We just like to take our time.
And that just means people don't need an application that checks every day or so for a new update.
It's just not as big of a pain point for the product portfolio that we have as it is for the product portfolio that other companies have built up.
Like, I think we have 16 products that we develop actively. But a lot of them are freeware and magazineware.
So when you bring it down to what we actually sell on our website and then to how many people actually buy everything, or just buy a subset of the catalog, then it's just not that big of a deal.
It's not that we haven't thought about it.
Occasionally, this topic comes up, and it's like, Wouldn't it be nice to have something that people can use to just install everything they have or update everything they have? But we usually don't talk longer about it. ;)
It just pops up sometimes in some chat and then people say, Yeah, it would be nice. And then nobody does it. :) And then more pressing things get done.
Yeah, makes sense. I once had an idea, but throughout talking to musicians and vendors, I realized that nobody was actually interested in my idea. :) When I had a studio, a rather big studio, I sometimes looked at the outboard gear and felt like, Oh, wow, this thing looks so amazing. Let's work with this today. The sonic aspect was not the primary driver to choose a device. I would sometimes chose it because I liked the knobs, I liked the feeling, the workflow, and I wanted to have a good time with it. And with the plugins, it sounds absurd, but I had a little tool programmed for myself that showed me screenshots of all the plugins I owned. So sometimes I just opened this list and went like, Show me all the compressors I have. And then I was like, Oh, wow, I didn't try this particular compressor for quite some time. So let's use this today. Because I think the plugins, and I guess probably most of the people that buy plugins are addicted to them to some degree, they kind of disappear behind menus or browsers. So, again, I had the idea that a plugin manager application, but that is more kind of visual, like gives you kind of a virtual studio o rack view where you see all your plugins, and you can also update them, etc., would be nice to have. But yeah, I realized that it would be a huge undertaking.
I agree with that. I would love if operating systems had something that would basically make this possible. There are package managers on Linux, e.g., which are really cool. But on Linux, they are so fragmented again. ;) And it would just be like, okay, now we have to support this package manager and this one and this one...
Flathub could have been something like this. Unfortunately, Flathub was built without plugins in mind. And usually, and that's funny, that's the default. macOS has a package manager, the App Store. It's not really made for plugins.
Windows has the Microsoft Store. It's also not made for plugins. It's like nobody cares about plugins. ;)
The plugin aspect is something that most platform developers don't really think about. So that means we are back to our own efforts. We would have to make our whatever updater, as other companies usually much bigger than us have done.
Then it's usually something like, Do we really have to do that? And honestly, you have more interesting problems to solve. Like a new product. That's often how it ends.
By the way, some people make unofficial packages from our plugins that script the download and installation from our servers. There are some of our plugins on brew (macOS package manager) and on chocolatey (Windows package manager).
That reminds me of the AUR, right? Arch users tend to have a first look at packages in the AUR and often install it from there.
Yeah, it's true. I actually don't know if u-he plugins are in the AUR, I didn't check.
I think there are at least some, but I don't know for sure. I never really used the AUR on Manjaro and haven't started since I am on Arch either. On Manjaro, the AUR always felt somewhat dangerous. ;) So I never really became a fan.
It's a good choice. Yes, on Manjaro the AUR can be dangerous.
So the last question that I have, I think you spoke a little bit about it already, is collaborations and in particular the one around CLAP. All I know is that its creation has been an effort between Bitwig and u-he. And, you know, for my Linux Audio Plugin Development initiative, one of the goals is actually to connect developers with each other, like with know-how and collaborations. As a practical example, one big pain point on Linux is always window resizing. I don't know why it is like that; I'm not a developer, but many plugins struggle in that department. But some vendors seem to have figured it all out. You know, they seem to have found a way that works. Most go the safe way of providing like predefined window sizes anyway, but this would be an area where developers really could need help. So, my question is, did you enjoy the collaboration with Bitwig and would you like to have more collaborations with other vendors in the future.
Oh yeah, absolutely. We love the collaboration with Bitwig. I mean, we are kind of “befriended companies” anyway. Like, you know, we make events together and stuff; they are pretty cool. We like to hang out with them.
We also have all kinds of connections to other vendors, especially host companies, because, you know, sometimes users report something, and we're like, that's weird. Okay. And we have no idea why our plugin does something unexpected just on that one particular host. And that's usually when we connect with the developers from other companies and try to ask them, Hey, do you have any idea why this is happening? You know, sometimes it's a problem with the host, but sometimes it's something in the plugin specification. And sometimes it's something we have to change in our plugin. So we need this kind of discussion. We need it to happen because, in the end, the customer has a problem. You don't want to be like, Hey, this is only happening in that host. It's their problem. And then they're like, Hey, it's just happening with that plugin; it's their problem. You do not want that kind of situation because that really sucks.
So this is where discussion and collaboration is really useful because they can look at their code, and we can look at our code and we can say, hey, we are doing it like this.
And then also the plugin formats are not always very concise or very clear about how this one thing should be used. So often stuff is up to interpretation. And both interpretations of the host and of the plugin, can both be valid. And then you have to kind of, you know, agree on something on some middle ground, something that makes both interpretations work. So discussion is very much necessary there to ensure that your binary works on all of those hosts.
I think we just hit an hour. :)
Okay. Yeah, cool. Really cool. :)
I enjoyed it a lot. And this was all especially interesting for me since I'm a fan of u-he. <3
I just like to wrap something up from my side.
Like, at some point, I had the feeling that I was maybe blaming or complaining which I want to clarify. As a developer, I'm more focused on recognizing problems because I want to improve them.
I use Linux a lot for everyday tasks, developing and gaming and I love it. It works great and I rarely run into an issue, which mostly evolve around running plugins via WINE.
And all the music and audio production things that Reaper and Bitwig are making possible on Linux are excellent, too.
Like the last three years, I could actually start doing so much more on Linux than I had been able to do 10 years before that.
I did not have that impression. But yeah, my focus is, of course, totally on Linux. I also would not know what to say about Windows at the moment or even macOS. But you know, I get it. I have to add, that for me, problems are not really problems, if that makes any sense. :) For me, problems are opportunities. And also, when you look at software development in general, I often realize that the most polished experience is where a ton of resources have been thrown at. And I still sometimes cannot understand how Open Source works when you look at those merge requests and the comment sections, and how people are working together from all corners of the world to actually create something truly fantastic together. And I think Linux has come a long way, and for me, in many aspects, feels super polished already. Better than the competition in some areas, even. But, yeah, there's still room for improvements. And I say to everyone who is interested in working with Linux, that if you want to invest energy and love into this and learn something, then it can be magical. But it can also be frustrating if you don't want that if you just want it to work, you know?
Yeah, yeah, it's not going to work by itself. This is kind of a thing that I would wish was there.
This is probably also where the points I made earlier lead to, I guess. I basically would love to have something for audio like what STEAM is for games. Something where you can just click on it, and it gets the right Proton version, sets the right configuration, thinks that all the emulated plugins work. For native software, it has all the runtimes shipped with it and cares about binary compatibility. I hope that someday somebody does it.
It's funny that you mention compatibility because, there are applications on Linux that have official support, but they are extremely challenging to get working on certain setups. One such example, for me, is DaVinci Resolve. The interesting thing about this is that people started to install DaVinci Resolve in containers, with Distrobox, where the underlying system components never change. Through that, it is made sure that the application installed in that container never breaks, even if your host system may be a rolling distribution that changes all the time. And something else I'd like to add. Have you heard of Sound Blocks by Nazaray? It is a music app that's distributed via STEAM.
Oh, I see. Interesting. Okay. Nice one. Did not know about Sound Blocks.
Distrobox is interesting. But I guess it doesn't work for DAWs that load binaries into their own address space. There you would have to use some kind of interprocess communications, which always comes with some kind of a slowdown. There are tricks against that. You can batch certain things, but that works best when the underlying audio signals are routed in parallel.
I think your initiative is a good thing. It's good to have this kind of resource where people can go and see like, Oh, there are these plugins for Linux, and there's that. And I also like that you are approaching it in a non “it needs to be Open Source or else...” kind of way.
Because, if it needs to be Open Source, it usually means someone has to do it in their spare time. And they might not have as much spare time as you eventually would want them to have.
It's basically a bit like how the world works, and not really like how I, personally, would want the world to be.
Of course, I would love to share the cool things we do if we would not rely on money, right? But we do.
Yeah, absolutely. But who knows? Maybe in a distant future, we all have a free income and everything will be Open Source. Who knows? But, right now, it's not like that. And I also don't per se think the experience with Windows is horrible. I don't think the macOS experience is horrible either. It's just like, I enjoy Linux and Open Source very much, and personally wish that the world will transform more in that direction, not only for software.
That's a nice approach, to be honest. I'm also working on all operating systems, and I love my MacBook and I also love my Windows computer for the stuff I do there. It's like, yeah, all the things have a place to shine.