Paul Davis, lead developer of Ardour on fixing big Linux audio issues

This is a the second part of the interview with Paul Davis, lead developer of Ardour, a free/libre digital audio workstation.

In the first part, we spoke mostly about all things Ardour. But now it's time to talk about some big stuff that is relevant to virtually every user of Linux audio applications for music-making. As with the last time, edited transcript is available below.

LibreArts · Paul Davis on fixing big Linux audio issues

Three years ago, at Linux Audio Conference, you were talking about things we got right and wrong in Linux audio. One of the things you said was that the audio system on Linux is too complicated but — and I'm probably misquoting here — it is now too late and we might have to live with what we've got. How much do you think we would have to blow up to rebuild Linux audio in a saner way? Do you think we are really past the point of no return?

I don't remember the precise comment that you're remembering. But one thing I do remember saying, and this could be it, was when I was involved with the Linux desktop architect group some years ago. There were discussions about what should we be doing about audio for the year of the Linux desktop or whatever.

And I was pointing a lot of people at PulseAudio. Because even though I was doing JACK at the time, I felt like PulseAudio was just a better choice for consumers. It just did more what they needed.

PulseAudio is now the default sound server, that's how we do things.

I think… I suspect that it is too late. I think, if you go back and look at what Apple did when they introduced what was then OSX but later got renamed back to macOS, they completely changed the entire audio API.

Nobody's existing software could be recompiled. There were no glue layers, there was no compatibility. The message to developers was just "Sorry guys, you have to reimplement this". And Apple had enough confidence that developers who were doing that kind of software would want to do that, that they just said "This is how it is".

But Linux doesn't work like the Apple platform. There's no big stick. And even if Linus was of the opinion "No, now we are just going to throw out and just replace the whole audio stack completely"… Even that isn't enough to make that happen.

And even if somebody did that, somebody would come along and say "Here is a compatibility library for ALSA". Because people did that with OSS which was replaced, and this library still exists.

That's true even for PulseAudio at the wish of its original creator. Nobody was even supposed to use the PulseAudio library, you were supposed to use ALSA, because PulseAudio would pretend to be an ALSA device.

So I don't think we have a big enough stick to come along and just say "Okay, we learned a lot but we got it wrong and we are just gonna do it over".

Now, the obvious question would be, well, maybe is there some incremental way, maybe it's not throwing it all away and maybe it's building more incrementally?

Pipewire is an interesting project. I'm very glad that its primary developer has changed his direction a little bit in the last 6 months. And I think he's taken into account a lot of good criticism from Robin and from some other people who are still quite involved.

So you kind of influenced him?

Yeah.

And I think that there is now a greater chance the PipeWire will be able to do what its goal is stated as. Which is to become a replacement for both PulseAudio and JACK. And if that happens, if it really is able to satisfy those goals, I think the situation is going to get a lot cleaner from some perspectives.

There will only be one sound server. It will do low-latency professional audio music creation stuff. It will handle output from your browser. It will handle desktop beeps and notifications.

However, that still leaves the question of what APIs the software would be using. And that continues to be part of the complexity.

Now, it's not the complexity that is unique to Linux. If you are doing audio software on Windows, and you say "Well, what audio API should I use?", it's a arguably at least as bad, maybe worse than on Linux. It's just a multitude of possible answers.

So the only OS that I've seen that has gotten it right is macOS. I would say they got nearly everything right. And the things they didn't get right are so small that it doesn't really matter a whole lot.

There is one API, it makes no difference whether you are trying to make a desktop beep or you're trying to write a digital audio workstation. It just works.

And if you are a user, and you want a glue to devices to make a combined device, it's a few mouse clicks. It's a great design.

PipeWire might get us there as far as user experience, if it meets the technical goals that it laid out for itself. But I think it's still going to leave this hole in the background for software developers, which is "Okay, so I want to write a piece of audio software. What do i do?". But at least that would be for developers to resolve. And users will not have situations where, you know, "Well, I'm using Ardour, my browser won't play audio", stuff like that. Those sorts of problems would go away.

Now, to do it like Apple did with CoreAudio… They actually moved a lot of the kernel functionality into a user-space daemon. That raises a little bit of hope for me that maybe you don't actually have to change the kernel and you don't have to change ALSA. Maybe we can get this all right by having the right user-space stuff.

I think we just have to wait and see what PipeWire looks like in another year, maybe year-and-a-half. And if it's really getting close to meeting is technical goals, then I think at least the user experience of audio on Linux will get dramatically better.

It's been 5 years since JACK in not hardwired into Ardour anymore. Lately, I've been catching conversations on the IRC channel about the possibility of ditching JACK support entirely. Now, I do know that you used a bunch of smiley faces when you said that but you've said before you weren't happy with how things turned out with JACK. So what's up with that? What are the main reasons for your disappointment with JACK and what's your long-term vision for Ardour and JACK?

So the backstory here is, yeah, I was the original author of JACK which got created out of code that came from Ardour originally. I still think JACK is an incredibly cool idea, if I say so myself.

But… It was created to address a very specific need which was the lack of plugin API on Linux for audio plugins. And the idea was that, instead of writing plugins people would write whole applications using whatever tools they want, whatever GUI toolkit, language… And then we'll just use JACK to connect them together. And this is going to be great. It means that the developers won't have to coordinate as much as they do with plugins and digital audio workstations. The workstation developers won't constantly be having bug reports from people like "I use this plug-in and it crashes". And the plug-in developers won't be getting emails like "I can't use your plug-in in this new DAW". It would be great!

And JACK does that, and that's awesome because the idea of sending audio and MIDI from one program to another just as easily as sending it from the program to the hardware or computer… I mean, this ought to be easy to do. And JACK does make it kind of easy to do.

But then we get into both the philosophical and just code development environment problems.

One problem with JACK is that it means that you have what some people would call a modular setup. You got a bunch of distinct programs talking to each other. You don't have any really good way to save the state of all the programs at once. We had attempts and they are not bad. But it's still nowhere near as convenient as using a single program that has everything happening inside of it.

And that creates an environment for a lot of users that, I think, is much more complicated than what they really want. Even the basic idea of JACK for a lot of new users, when they have to deal with that as the first thing they have to deal with… It's just not an obvious concept to them.

They are used to a computer where you click on the button, probably in a browser, that has a little arrow pointing to the right and a circle around it, and it suddenly starts making sound out of the speakers and that's all that has to happen.

And then you say "Oh, no-no-no, there's this cool tool, and it has a patchbay, and you have to set parameters' and all this other stuff".

Now, when you get deeply into it, when you are really involved in pro audio workflows and stuff, you start to understand, like, "Oh man, this JACK thing is actually really cool for some things". But it's really not something you want to put in the path of a person who's just starting out using this kind of software.

So that's one problem with it.

There there are some design problems, things that we never really did. Some things have been addressed by the metadata API that came out some years ago. It lets you, for example, put pretty names onto ports in JACK so that you know what they are. But we never really grappled with the issue of, you know, when you have a piece of hardware there, the hardware is normally identifiable by at least a name on Windows and macOS. And sometimes the channels have nice names. JACK works almost all the time to not do that.

"I don't even want you to know what sound card you are using, it's just called 'system'. And the ports are just 1, 2, 3, 4, 5, 6, 7, 8, 9…". So that's not there.

There are other issues, e.g. we never addressed looping in the JACK transport mechanism. Also, there's no latency in the wire in JACK, which means JACK can report latency but it cannot do anything about it.

So these are the technical problems that got in the way. And then there are, sort of, community development issues. Early on, Stéphane Letz started working on the multi-prosessing version of JACK. Which I thought at the time was a great idea. It was written in C++, it was going to do parallel processing etc. And it seemed entirely appropriate just to go down that route.

There's no point rehashing old history but Stéphane's efforts which became JACK2 never really merged, they never united with JACK1. They are compatible at the binary level but they have different capabilities for users. It's sort of a mess.

I handed the control over the JACK project to Filipe [Coelho] a few years ago. I'm successfully completely ignorant [laughs] about what he is doing and what has been done. And I'm happy to keep it that way. And so JACK will do what Filipe and the rest of the project wants to do with it.

You asked about Ardour and JACK… Yeah, there were smiley faces. I don't think we're ever going to drop JACK support. We do continue to run into problems — most recently, what I consider to be the crazy decision about threading where an application is actually processing audio and, in the middle of it, can be told things like "Oh, one of your ports just got disconnected" or "There was a latency change".

I didn't agree with Stéphane about this at the time and I disagree with it even more now. But yeah, we'll figure out workarounds for some of that behavior. And I don't think the support for JACK is going anywhere.

But we do now generally tell new users "You don't have to use JACK. And in fact, if you don't use JACK, your initial experience is going to be a lot easier". That's particularly true for MIDI devices. Most people using JACK2 have to go through some extra loops to actually get hardware to show up. Whereas if they use the ALSA backend on Linux, it just works.

So JACK will be there, we will suggest and make it more and more obvious that JACK is not the obvious thing for you to use.

There's been a lot of talk about session exchange between Ardour and other digital audio workstations. I know you've been extremely unhappy with OMF and AAF. And I know you've been so unhappy that you even promoted AATranslator which is proprietary software for project files conversion, mostly because it took that weight off your shoulders, I guess. But I recently heard Robin and you, I think, commenting positively about OpenTimelineIO (OTIO), although that project is more commonly associated with video production, mosdtly has adapters for software like Final Cut Pro X. Do you think OTIO is the way forward?

I think at this point it is still a difficult question to answer. I only had a brief look at the API and the specification for OTIO. It's hard to understate how much of an improvement it is over OMF or AAF. It is a vast improvement over what was going on with both of those "standards". I mean, OMF is barely even a standard — you can't even really get the specification for it. I will also not that both of those two, OMF and AAF, are also primarily associated with video.

I think that the critical issue with these formats from my perspective is, are they sane? AAF is not sane, AAF is insane. AAF is an example of what happens when you have not one but three committees. When you have ideas like "Ah, well, we don't want to specify what the file system is, how files are represented, so we will use some Microsoft thing that lets you put a file system inside a file and that will be our way that we talk about files". It's just insane.

There's good signs that OTIO is a huge step up from that mess. So some of the worst elements of even thinking about doing AAF support go away.

We are also living in an era where generally the open source contributor based mentality promises that, one way or another, that library and that standard will just get better.

Again, I haven't looked at it in enough detail, but the other part is how well they represent the audio aspects of what you need as a session format.

If you only represent the totally straightforward non-linear editing bits to match audio like "This file asset source something, we need this bit of it and it goes at this point on the timeline", well, it's okay, at least you could do that for audio. But actually, to make it useful as an audio session format, you need a lot more information beyond that.

I don't know how far down that path they've really gone. There's an open question about whether or not a session format should even attempt to try to represent plugins. It gets quite complicated because, you know, if you got AudioUnit plug-ins, they don't run anywhere but macOS.

I am not familiar enough with those audio-specific elements of the representation in the file format specification to really know how good of a future it looks.

But if they can get those at least adequate, then it offers some hope that audio applications like Ardour could start maybe using and supporting that format.

Which with AAF is never gonna happen, and even with OMF… I don't know why but Reaper's support for OMF was opensourced. So I actually did a [git] branch a few years ago, added that to Ardour. And it turned out that, you know, it supports maybe 1/3 of all OMF files. It's just another indication how appaling the specification and standartization is.

So I'm cautiously optimistic. I think the other thing that's interesting though is… I've heard a refrain from a number of people that said that actually this whole notion of being able to move sessions between tools just isn't really a thing for most users. Especially for whatever number of recording studios still exist in the world after this virus.

You don't want to make it easy to just take the session that you created in this recording studio and have them take it home and use a totally different tool to work on it.

So, like, do the stem exporting and be glad of it?

Yeah, be glad of it. But also this story of migration just doesn't happen very much. The one area where I think it is more relevant is the video editing to DAW and back and forth. So basically in a movie post-production or even production stuff… That does seem like a much more legitimate case to me where there's one person working on the video side and they use this tool, and then we have this guy working on audio with another toolset. And it seems right natural in that context to go back and forth really easily.

And so that is the one use case for this kind of support that really makes sense to me. The bit that doesn't make sense is "What? I use Ardour but my friend uses Cubase, I want to be able to go back and forth with him". It's like…

No…

No! [laughs]

Actually speaking of plugins… Another thing you said in that LAC talk was something along the lines of, the fact that U-he were able to develop the Zebra synthesizer so fast, and we only have this many good virtual instruments means we are doing something wrong. But there is now an even more staggering example. The VCV Library now has 2,000+ modules. VCV Rack is also free/libre software, it has only been around for three years. LV2 has been around for well over a decade, and the last time I checked there were about 1,000 related repositories on GitHub, most of the plugins not easily installable, you have to compile some of them. What lessons do you think we could learn from VCV and how can we realistically improve the LV2 ecosystem?

Well, let me first say that I have just an incredible amount of respect for what Andrew [Belt] has done with VCV Rack. As an audio software program, it has some technical issues inside of it that bother me. But… As a user of it, which I am, it's an amazing piece of software.

But even more amazing than the software is the ecosystem he has built around it. Which you just mentioned. It got over 2,000 modules. The ease of getting these modules, of using them in the program is just completely exemplary. As well as the way in which the project has drawn in all those people who are actually involved with hardware modular synthesis and even other software modular synthesis environments and even people who are just completely new to the whole thing.

It's just incredible and I have the utmost respect for what he has done. And it makes me a little jealous…

In a good way? [laughs]

Yeah, in a totally good way!

I'm also very happy as a user of the program because it's just all those incredible modules out there to do really great things with.

Now that being said, there is one element of what Andrew has done with VCV Rack in terms of facilitating modules a lot simpler. Which is when you run a module for VCV Rack you are literally running a module for VCV Rack — a plugin in many, many ways by comparison with other sorts of VST plugins or AU plugins. But it is actually a plugin for a specific program, not a whole suite of programs. And so in one simple move you've just wiped out a huge number of the problems that plugin developers have to face, like, "Which host am I targeting?".

In fact, Andrew hid a lot of platform-specific stuff too. Of course, someone still has to build and compile plugins. So developers who want to honor the three platforms tradition of VCV Rack — Linux, Windows, and macOS — still have to grapple with the fact that they have to build them for people to use. But when you write them, there is almost no platform-specific stuff.

So he's done something that's mildly equivalent to what is increasingly happening in the web browsers now — they are entire development environments.

VCV Rack is this completely closed system, and I mean it in a good way, not in contrast to libre/open aspects of it. It is just what it is, and when you write a module for VCV Rack, that is all you are doing.

You don't have to think which graphic toolkit you should use, what are the subtle details of how you do critical sections on Windows vs macOS. All that goes away. You just have a pretty simple SDK to work with, a brilliant design of how the module graphics should work.

And that gets rid of a lot of the complexities of doing actual traditional plugins. I think that's one of the reasons why it's been so successful. I think what Andrew did with the environment and the ecosystem has made that really easy to do. And I think that it's not really very easy to do that if your target is not one host program or platform.

Also, no audio plugin API completely specifies the graphics part. And so every developer has to deal with this question: "How am I gonna do the graphics"? And on Linux, that's even more of an issue than it would be somewhere else.

So to me, one of the lessons is that if you build a much more constrained environment, but it's still very powerful, lots of people will be interested and lots of things will happen.

Now, it doesn't happen all the time. Reaktor, for example, normally should have been just as successful. As far as I can tell it just isn't. Lots of people even like Reaktor and use it. But Rack has just exploded, it's a meme, it's part of what people are doing now.

But the other thing is that it's open, it's libre, and it's cross-platform. And I think that also drives interest because any developer who starts thinking "Maybe I'd like to do a module", it makes no difference what platform their users are on. Users don't have to care.

They [developers] might. Although maybe Andrew has taken care of that in the website backend, maybe all you need to do is to upload the source code, and it will build the modules for them.

So constraining environment but making it super powerful and cool and unconstrainin the project and making it so that people who want to get involved in that are not sacrificing anything by making a decision. And guess what — people will just flock to it.

I'm not sure that we can really take that model and use it for example for pluging in your digital audio workstation unless you're talking about a super simple one.

I think you could argue that a tool like LMMS in Linux world… I mean, LMMS is a much simpler kind of environment than Ardour, Logic, or ProTools. And I think you could make a case that you could come up with a design for a very constrained digital audio workstation that would have the same kind of appeal, maybe it would have its own plugin format, it was cross-platform, all graphics got taken care of the same ways as modules are in Rack. But that would be a very constrained tool that would be of no interest to anyone.

Also, for users, there are tools like that out there. But VCV Rack was new, it wasn't just done in all the right ways, but it was something that didn't really exist until it came along. It does share some similarities to pre-existing software. But it just did so many things so right that it opened up new ground for people, that's why it is so successful.

With something like LV2 which is another plugin API in a sea of plugin APIs, one that doesn't really solve many if any of the problems that plugin developers are gonna face,… I think we just can't have that kind of success in the world.

What I think is encouraging is the fact that there are now several plugin development toolkits that make it almost as easy if not as easy for developers to do Linux VSTs, for example, as AudioUnits or Windows VSTs — and maybe generate LV2 plugins as well.

And that type of thing does open up the possibility for a developer to generate a plugin for everyone. And maybe that levels the playing field a little bit more. Maybe there's more people who want to do really cool stuff, and the end result will be that their work is available for everyone. Not neccesserily without cost, not neccesserily open source, but available.

So cross-platform plugin development toolkits are more analogous to what VCV Rack pulled off than the plugin APIs themselves.

But yeah, Rack is just… I have to avoid using it because I could just waste most of my life [laughs].

You know, actually, sometimes it feels like Ardour is a testbed for experimental LV2 extensions. It was first to use the mixer inline extension. Then there were extensions for matching dpi and colors between host and plugins, if I'm not making this up :). And I don't believe it's going to stop at this. How comfortable are you with it?

Oh, I'm pretty comfortable with it. I think this is part of a whole point of LV2. And what has happened with that in Ardour is, I think, a really good demonstration of the power of the design of LV2.

Which is that all it takes is an agreement between one host and one plug-in or one plugin developer. And all of a sudden, you can add cool new functionality without actually having to change the API or meet with some standards body or anything else. There's no equivalent of that whatsoever for VST and AU, you can't do that.

And as we work in the context of a digital audio workstation, most of the proprietary DAWs have their own internal plugin API. And they come with their own proprietary plugins that come with the workstation, and so they can do whatever they want there. They don't have to publish it, they don't have to talk about it. They can just create whatever mechanisms they need for the plugin and the host to communicate and do whatever they want.

With Ardour, we sort of use LV2 that way but we are not corrupting LV2. We are using it in a way that was intended.

Another example of what you mentioned, one of the things that we've worked on is the plugin-provided MIDNAM data. So MIDNAM is this format where you can describe the names of MIDI notes, the names of patches and programs, and generally annotate a MIDI-controlled synthesizer.

But MIDNAM files are normally just files. So we need a mechanism for the plugin to tell a host: "Here is my MIDNAM". So we now have an extension for that, and plugins can provide a MIDNAM. We provide it in the general MIDI synth that we include, and there are at least a couple of other LV2 plugins that now provide MIDNAM files too, I think Helm is one of them.

Doing this in the context of any other plugin API is possible. It is something that Reaper has done with VST, for example. They have at least half a dozen extensions to the VST API. These are not part of the official standard and not fully documented. So it's just Reaper waving a hand and saying "Hey, we do this!".

Whereas with LV2, you can actually say: "Here is the spec for this extension. And it's written down and this is how it works". So I think this is a great thing and I don't think it'll go away.

Do you think it helps that David Robillard [main developer of LV2] works for Ableton now?

As far as I know, David keeps his work life and his open source life fairly separate. So I don't think his work inside of Ableton really helps the LV2 situation very much.

But I think David is a great asset to what LV2 is and can be. And I think the fact that he works in the context where he gets to see other aspects of how this whole audio software world works probably can't hurt.

There have been several attempts to build commercial Ardour offsprings. As far as I can tell, Mixbus is the only one still alive and doing very well after over 10 years in business. Apart from contributing code to Ardour directly, they also employ Robin Gareus, whose level of involvement with Ardour development, I dare say, rivals yours. Do you think they've been successful because they are so heavily invested in improving the upstream project? Or are there other reasons at play?

As you said, there have been a few attempts at doing some commercial spin-off from Ardour. Mixbus was the first. The second one would never really got off the ground was with Solid State Logic. And the third one was working with Waves Audio on the Tracks Live project.

What I can say by comparing all these three is that there are some important things about Harrison's approach to this that helped along the way.

First of all, I assume it was Ben Loftis at Harrison who understood and had a very clear picture in mind early on of how they could do something with a GPL piece of software and make a product that would work for them and be viable. Maybe Ben didn't really know at the beginning, but it might be.

And I think, in contrast, Solid State Logic really struggled with this idea: "How could we ever do anything with this if it's open source? What can we do? This doesn't make any sense!".

There were other reasons why SSL dropped their involvement with Ardour. You know, giving them the benefit of the doubt, relatively understandable and not really a verdict on Ardour itself.

But they really struggled, they couldn't even really come up with what the starting step should be. Because they couldn't imagine what the end was gonna be. Whereas Ben and Harrison in general could do that.

Behind the scenes, Waves have been very strong supporters of what I've been doing for the last 15 years. And I really like some of the people who work there a great deal.

Waves Tracks Live did become a product and they did release it and it did get good reviews. It was a part of a strategy for them to get into their own digital audio workstation. But it was decided that instead of jumping all the way into a studio one it would be better to start with a more constrained thing.

Track live was intended for use in live situations. And as an aside here, there was a really great experience for me. Before I left Philadelphia, I got to see Nils Frahm, German contemporary piano musician whose music I like a lot. And as I was standing up on the balcony level, I looked down and realized that his audio engineer was using Tracks Live to record the whole thing. I went up to him afterwards and asked him how it works. He said: "Oh, it's great! I does just what I need! I love this software!". And I said: "Well, I wrote that". And it's a whole different experience when it's happening at a concert of somebody whose music you really like. That was cool.

But anyway, it was a somewhat successful product that is still available. I think it doesn't even cost anything anymore. I don't think they charge for it. But Waves also had this problem. They didn't really quite know where they wanted to go.

They weren't even so much as appaled by the GPL. Their reason why they wanted to do this wasn't "Oh, we are gonna make tons of money by having a new DAW". Their goal was "We wanna do certain things, we are a plugin company right now for the most part. So we want to get to a place where we can try cool ideas and some conceptions we have for some new technologies. We can't do that unless we control a host. So we need our own host, a workstation".

Yeah, it looked a little like they needed a DAW for their own MADI interface.

Yes, but there's also some ideas that they have… You know that I signed an NDA form and can't speak freely, so… Some ideas to do with mixing and how to get really great mixes on a song and so on. But if you don't control the whole DAW, it's difficult to do.

Waves wanted to go down that path because they had some ideas for things that they felt they needed in their own workstation. And they had already been involved with me in various ways over a number of years, and they said: "We like the idea of Ardour, let's start from there".

But Waves had a different problem: the developers that they hired didn't have any experience with cross-platform desktop GUIs, although their entire plugin team uses Qt. They were used to using rapid application design tools where you essentially mock up the entire GUI, and it spits out a bunch of code, and nobody ever sits down and says "Oh, put this button here" etc.

And this approach has a couple of benefits. One of them is that you can have a designer working on the GUI, and they don't have to write code, they hopefully know about good design. I'm sure Martin aka "Tantacrul" would disagree with this! [laughs] But anyway, with this approach, you don't have to frequently rebuild the software when the designer decides to change the arrangement of things. The other benefit is that you completely separate the design from the application's logic.

So the programmers they hired were used to this approach. When they started looking at Ardour where everything is done in code… I wouldn't say it blew their minds, but it's just the concept they couldn't really deal with. And because they wanted to really change some really significant elements of the user interface…

Which they did…

…Which they did… This is a really big culture clash and it made it very difficult to integrate what they were doing with Ardour's source code.

And although Tracks Live was successful and although there are some things that came out of that work that are in Ardour now, we were never able to really connect and stay connected.

With regards to Harrison, that is exactly what has happened. Harrison's commitment to the GPL, to "we are not gonna to redo the whole GUI"… Ben probably pulled his hair out multiple times, "GTK! I can't believe this!" [laughs], but, you know, they've been willing right from the beginning to just say "No, it is what it is". They understood that switching the toolkit was not going to solve any problems. And they've been willing to be deeply integrated into the Ardour process as well as the Mixbus process. And so the two projects have been able to evolve side by side.

What used to happen with Tracks is that they would give the work they had been doing for a month, and then I would have to spend two days on my git merge. It was just a complete mess.

Robin does the merges between the two [Ardour and Mixbus] and I have never really asked him in detail how it is. But I get the impression that 90% of the time it's completely easy. And in fact I know they've even put more effort into trying to make sure it is easier instead of more difficult.

So I think, with Harrison, they had a vision for how they would be able to do something interesting and cool and useful and hopefully helping them to pay for what they do. They had that from the beginning. They have been willing to deal with the technology that is in Ardour as-is, particularly all the GUI stuff. And they've been happy and able and willing and really valuable to be very integrated into the Ardour development process.

That's why I think those three things made a huge difference. Even though Tracks Live was — when it initially came out — probably more successful than whatever Mixbus version was then. So it's not like you can't have some momentary success but I think part of the reason why Mixbus has that long-term success is those three things.

Combined with the fact that it's a pretty cool idea and for a lot of people it sounds really good. You know, they just put their sessions into the Mixbus and it sounds more like they think it ought to sound.

So these four reasons combined are part of the reason why they've been really successful and the other attempts to do this are not. I'm not saying noone else can do that as well in the future but I do feel very strongly now that somebody has to have those first three conditions or it's not gonna work.

They got to understand how they are going to work on something available under the terms of the GPL.

They got to be prepared to accept the GUI technology for what it is.

And they should be willing to be fairly integrated with what we're doing. Because otherwise things just diverge and they can never be reconnected.

If there are companies are out there that have ideas and they think they can work within those constraints, then I'm all for more collaborations or even just forks. But without those three I think it's probably not gonna work elsewhere.

All interviews take time. There's always the research stage, conversations on and off the record, filing bug reporst, editing — especially in podcasts — etc. The thing that really consumed a lot of my time here was preparing theedited transcript for people who would rather read the text. So if you enjoy the work I do, you can support me on Patreon or Liberapay, or make a one-time donation .