[PaulDavisThe1st]

> Also consider that there are no good audio drivers for Linux (like Asio for example) so you're almost forced to stay in windows or Mac...

This is false.

> Imagine if they applied something similar to a git versioning system to music projects.

People have done this. Using git itself is a little problematic because it is very line-oriented and most project file formats for DAWs are not.

Regarding plugins, I know that I'm not the only lead developer of a DAW who, if they possibly could, would refuse to support plugins entirely. The problem is that most users want more functionality than a DAW itself could feasibly provide (they also sometimes like to use the same functionality (plugin) in different DAWs or different workflows).

There are things close to DAW functionality that have a CLI (such as ecasound). You can also run plugins from the command line by using standalone plugin hosts. You can use oscsend(1) to control plugins inside several different plugin hosts.

It sounds to me as if you've worked with a relatively small number of DAWs on only Windows and macOS and are not really aware of the breadth or depth of the "field".

[dewert]

> > Also consider that there are no good audio drivers for Linux (like Asio for example) so you're almost forced to stay in windows or Mac...

> This is false.

This was my immediate thought as well. Not sure what level we're talking here, so sorry if I'm addressing the wrong part of the stack, but JACK on Linux has been a great experience for me in terms of latency and ease of use. I run into way more day-to-day problems on Windows.

What feature specifically are you missing on Linux?

Re: plugins, DAWs with VST sandboxing are great. I use Bitwig, and I've never lost work due to a plugin crash.

[noahadavis]

And now that we have PipeWire, getting low latency audio is extremely easy too.

[lolcat_cowsay]

JACK is also really easy to setup with PipeWire.

[hammyhavoc]

PipeWire is love. PipeWire is life. Doing post on a documentary whilst using PipeWire. Linux for audio is finally there.

[officeplant]

>Re: plugins, DAWs with VST sandboxing are great. I use Bitwig, and I've never lost work due to a plugin crash.

Exactly, the original thread reads as someone who hasn't touched a modern DAW from the last 8 years or so. Even Renoise has multicore support with sandboxed plugins so one of my ancient free shitty vsts doesn't bring down the whole system.

[stevefolta]

> Using git itself is a little problematic because it is very line-oriented and most project file formats for DAWs are not.

Ardour and Reaper use plaintext project formats that work well with Git, at least for basic versioning.

> Regarding plugins, I know that I'm not the only lead developer of a DAW who, if they possibly could, would refuse to support plugins entirely. The problem is that most users want more functionality than a DAW itself could feasibly provide (they also sometimes like to use the same functionality (plugin) in different DAWs or different workflows).

I think the answer to this would be something like Reaper's "JS" plugins, which are written in a small compiled language and distributed as source code. Compared to "JS", it would need to: 1) be open source; 2) be a better language; and 3) support pretty skeuomorphic graphics ('cause people seem to really want that in their plugins). Ardour seems to be working on something like this using Lua (don't know about the graphics, or if the plugins could be supported in other DAWs).

[PaulDavisThe1st]

Ardour uses XML for its session format, which is not a line-oriented format. Git can handle it, most of the time, but is not ideal. Something that groks the concept of XML nodes would do a better job (i.e. less conflicts duing merge resolution).

Ardour comes with a small set of basic "curated" plugins written in C or C++, that are "blessed" by us. Writing DSP plugins in Lua is also possible, but generally discouraged and, as you guessed, you can't provide a dedicated GUI for them, nor can they be used elsewhere (same limitation as Reaper's Jesusonic plugins).

However, even if those details were improved, the idea that a DAW manufacturer is going to be able to supply the precise EQ that demanding users want, let alone noise reduction, polyphonic pitch correction, and so, so much more, strikes me as unrealistc.

[tialaramex]

Note that git's diffs and merges are customisable. If somebody wants to put in the effort for a particular format, they can write tools that perform these two specific tasks and git can be told "Here are the tools for this repo" and deliver the benefits of improved tooling. It's definitely possible that could be worth doing for a DAW if used with git.

Git even understands that it's possible that you can neatly summarise a change in text (for display e.g. as part of the change log) but that summary is not actionable (so the data stored to implement that change is different), e.g. I believe git's man pages provide an example showing how you can get EXIF from a JPEG so that your git tools say the change was from "Photo of Pam and mummy" to "Cropped image of Pam" when actually it's a huge binary data change that is unintelligible to reader.

[Arelius]

I mean, If git's been around for ages by now, and this doesn't exist for even json + xml already and robustly, there must be some sort of problem?

[jacquesm]

The problem is quite simple: if it isn't supported by the base installation it might as well not exist. Github/Gitlab is how most companies and people now experience git, and afaik you can't add those custom plug-ins to those platforms easily if at all.

[wizzwizz4]

The tools don't preserve the literal contents of the file; only the JSON / XML semantics. This makes them unpopular. (Source: I decided not to use them because of this; I needed hashes to remain stable for some reason I can't quite recall.)

[Elv13]

> you can't provide a dedicated GUI for them

You could expose enough GTK bits to expose an event loop to the LGI lua library. It's gobject-introspection for Lua. Since you already use these libs, it would not make Ardour any bigger.

I am not saying it's a great idea to mix GUI and a realtime DSP in the same thread, but it would be supported in you see some demand there.

[PaulDavisThe1st]

I've previously written a long-ish article about the role of Lua/scripting in general in the context of a libre & open-source DAW before:

https://discourse.ardour.org/t/is-open-source-a-diversion-fr...

There's really no technological reason for not allowing Lua to create GUIs within Ardour. It's more a question of whether or not we actually want to. Either way, you would not be mixing GUI and realtime code - the architecture of Ardour doesn't allow that.

[diskzero]

Nice article Paul. It is motivating me to take another look at Ardour. I have also worked on some very large audio/video authoring tools. When we made the new lighting tools at Dreamworks, you could only create the UI using the scripting system. I am not sure if that discipline is still observed, but it was a good way to make sure that there wasn't a 2nd class citizen status given to extending the UI.

[PaulDavisThe1st]

Thanks. Thing is, in an open source system, there are no 2nd class citizens caused by the "eat your own dogfood" rules (or lack thereof). You want to change the GUI in Ardour? The code is all right there.

The question I was raising (which I think you understand) is whether most users care that this is possible if it can't be done without a rebuild (compiling).

[jacquesm]

I've been reading all of your comments in this thread and the links provided carefully, thank you for all the great work on Ardour and the degree of forethought that goes into it, it really shows in the final product.

[kortex]

Just use DVC for any non-line-oriented files. If you don't want cloud backing stores, it's pretty easy to set up using the "local remote" pointing to a custom path (e.g. External drive) if you are the only person working on it. Otherwise I'd recommend symlinks.

www.dvc.org

[tomc1985]

> Regarding plugins, I know that I'm not the only lead developer of a DAW who, if they possibly could, would refuse to support plugins entirely. The problem is that most users want more functionality than a DAW itself could feasibly provide (they also sometimes like to use the same functionality (plugin) in different DAWs or different workflows).

Honestly the sound quality of most DAWs' built-in effects and synths are garbage. Even the effects section of most VST synths is bad! Best to allow plugins rather than trying to reinvent the wheel; you'll have to pry my beloved serum/iZotope/u-he/softube plugins out of my cold dead hands

Also, the "sometimes" is an understatement. Anyone who's been doing this a while likely to be pretty invested in the plugins they have. I would say the majority of working musicians that use DAWs work this way

[lavabiopsy]

I think you are misinterpreting that comment, I believe the idea there would be to have built-in functionality that would be equal or surpassing to those plugins, possibly by merging the actual plugins with the DAW. Of course doing that in a way that will please everyone is a lot harder to do than it sounds and is likely not even feasible, but the supposed benefit would be that the DAW could better integrate that functionality and would not have to deal with a lot of the reliability issues that exist with plugins. (Disclaimer: I agree with the GP comment in the sense that dropping plugins from DAWs would be a great thing to do if it were at all possible, but it currently really isn't)

[tomc1985]

The thing is, doing something that would 'be equal or surpassing' is pretty much impossible at an acceptable cost. You can probably write something that's 'good enough' that some people might be happy with -- that is what most all-in-one DAWs do -- but the beauty of the plugin system is that you can delegate development duties for those components to someone who a company who specializes in effects, for example. Or even a specific effect! There are developers who just write synths, or just write reverbs, or whatever. And we want to use their products!

[lavabiopsy]

That's the thing though, not having plugins would not mean that you can't delegate development duties for a synth or reverb out to another company. I am not sure where you are drawing that conclusion from. It just means that the development would be happening within the DAW.

[tomc1985]

A large part of the reason those developers can exist independently is because they can target every DAW. So either you will have to hire them all or find new specialists, or develop that specialization yourself.

Even in the case of developers only targeting one DAW (Pro Tools), at least one company (AIR music) saw that it was worth the extra effort to release its products in other plugin formats like VST.

Honestly, I would not like to see new developers trying to oust the plugin standard. It's one of those quirks about music software that exists for very good reason.

[lavabiopsy]

I'm sorry, I don't get where this is coming from, the specialists don't need to be hired to write the same code again. The old code can just be re-used. If I could guess, I think this is stemming from a misunderstanding that "no plugins" means "no code re-use" which is an understandable misunderstanding (say that 5 times fast) but it isn't the case.

In my opinion, plugins only exist because it's convenient to package a synthesizer/reverb/whatever for users that way, but there is no reason that can't be supplanted with something that is more convenient. Of course if it's less convenient then that wouldn't be worth doing, if that is your concern then I agree with you there.

[PaulDavisThe1st]

Why would people who can sell (or at least pitch) their plugin(s) to the users of 12-20 excellent DAWs decide to go work for just one of those DAWs ?

[lavabiopsy]

I don't understand why you are saying that either, please explain. Nobody needs to work for just one, as any code can be linked into any number of DAWs.

[PaulDavisThe1st]

It wasn't really a misinterpretation.

Merging plugins "with the DAW" is entirely feasible in the open source world where I live and work, and we do that sort of thing when appropriate.

But the reliability issues do not come from the fact that plugins are dynamically loaded shared objects (mostly); they come from the vastly different levels of skill AND very different interpretations of subtle aspects of plugins APIs (notably threading, GUI<->DSP communication and more). These are hard to get rid of if you've really got a diverse, distributed and largely independent "team" of developers working on something.

[lavabiopsy]

I still don't get how that is related, in my opinion, that is unlikely to change until there are tools that make it easy to resolve all those various threading/communication/latency issues on the developer side before a plugin is even distributed. So as long as you can just distribute any old shared object to get around that, I don't expect to see it to improve.

Maybe someone could come up with another way to do it that works across DAWs, and then plugins could still happen, but I consider this unlikely because with that there is never going to be a reliable way for the host to verify it that works better than what we have now (user reports X plugin works with Y host, etc).

[PaulDavisThe1st]

It's not hard to stress test plugins. There are a few good tools for some formats out there. They can verify things that most DAWs will not (e.g. by deliberately cross-threading calls and so forth).

The problem is getting people to care. For years, on macOS, the "standard" for plugin developers has been "does it work in Logic?" There were even plugins that would fail auval(1) (the command line AudioUnit validator), but somehow pass in Logic. As far as their developers were concerned, the plugin worked. Working on Ardour, I've seen at least a dozen plugins that used ambiguity in the AU spec to justify why "well, it works in Logic even if it doesn't follow your interpretation of the spec" was the end of their interest.

[lavabiopsy]

That's what I mean. The solution there would be to get Logic to run "auval" before loading the plugin which ensures that developers don't do that. But for users of Logic doing that serves no benefit as it doesn't actually guarantee the plugins run more reliably, so it won't happen. And even if it did happen, there would be no guarantee that the stress testing tool wasn't also written against other ambiguities in the spec.

Edit: I also think testing is hard in general for plugin developers to use correctly. I personally would prefer to see plugin APIs designed in a better way that make it so it's hard to accidentally cause race conditions.

[officeplant]

>Honestly the sound quality of most DAWs' built-in effects and synths are garbage.

Have you ever tried Reason? Then again I'm actually using Reason as a plugin (via vst3 to vst2 wrapper) so I can sequence it easily with renoise. Because why not just load a DAW in your DAW.

[tomc1985]

Hah, I have a copy of Reason Lite that I got for free that loads as a VST. Mainly use it for ReBirth, but now even that's redundant since FL has its own 303 emulation that's pretty good

Back in the day producers used to complain that you could recognize a Reason track from a mile away. FL used to have the same problem. 'Garbage' is probably an overstatement nowadays (at least judging by the FLStudio demo tracks, their quality has been steadily improving over time) but the meme persists.

[officeplant]

For sure, Reason 3 and older especially had it's own recognizable sound.

Personally I like using "garbage" plugins in my music. I've gotten some nice strange out of old free vst plugins run through much nicer effects racks.

[wwweston]

> This is false.

Suffice it to say that it's non-obvious to me where to start to go about getting a stable and mobile (ie laptop) experience. I'd like nothing better than to receive a response that makes me feel sheepish for thinking that Linux is the problem, and if anyone can give out good pointers I'd imagine you can.

[PaulDavisThe1st]

Well, first of all let's start with noting that hardware can prevent you from ever getting a stable response. Some explanatory background on that here:

https://manual.ardour.org/setting-up-your-system/the-right-c...

On Linux you do not (as a rule) install device drivers for your devices. They come with the system or they (generally) don't exist. I know of only one audio interface manufacturer who ever maintained their own drivers outside of the kernel tree (i.e. not part of mainstream Linux) and even they have had their drivers integrated now.

Next, since you're on a laptop, you're relieved of the unenviable task of figuring out whether to use a PCI(.) bus device or a USB interface. USB is your only option. The good news here is that any USB audio interface that works with an iPad also works on Linux. Why? Because iPad doesn't allow driver installs, and so manufacturers have been forced to make sure their devices work with a generic USB audio class device driver, just like they need to do on Linux. With very few exceptions, you can more or less buy any contemporary USB audio interface these days, just plug it into your Linux laptop (or desktop or whatever), and it will work.

What can be an issue is a lack of ability to configure the internals of the device. Some manufacturers e.g. MOTU have taken the delightful step of doing this by putting an http server on the device, and thus allowing you to configure it from any browser on anything at all. Others have used just generic USB audio class features, allowing it to be controlled from the basic Linux utilities for this sort of thing. And still more continue to only provide Windows/macOS-native configuration utilities. For some devices, dedicated Linux equivalents exist. Best place to check on that would be to start at linuxmusicians.com and use their forums.

Beyond the hardware, it's hard to give more advice because it depends on the experience/workflow you want to use. If you're looking for something Ableton Live-like, Bitwig is likely your best option. If you want a more traditional linear timeline-y DAW ala ProTools, Logic etc., then Reaper, Ardour or Mixbus would probably be good choices. If you want to do software modular, VCV Rack is head and shoulders above anything else (and runs on other platforms too).

There's a very large suite of LV2 plugins on Linux. Stay away from CALF even though they look pretty. The others range from functional to excellent. Your rating will depend on your workflow and aesthetics. You will not find libre plugins that do what deeply-DSP-oriented proprietary plugins do (e.g. Izotope, Melodyne), though you may be satisfied with things in the same ballpark (e.g. Noise Repellent and AutoTalent).

There's a growing body of VST3 plugins for Linux. If you're looking for amazing (non-libre) synths, U-he has all (?) their products available in a perpetual beta for Linux. Great stuff. There are plenty of libre synths too. There's an LV2 version of Vital called Vitalium which is more stable than the VST3 version; this synth has had rave reviews from many different reviewers.

Sample libraries are a problem because most of them are created for Kontakt. You have a choice of running Kontakt inside a Windows VST adapter (e.g. yabridge) or using other formats such as SFZ or DecentSampler, both of which have both free and libre players. pianobook.co.uk has hundreds of somewhat interesting sample libraries, many (but definitely not even most) of them available in DS format.

Hope this helps.

[wastholm]

> Stay away from CALF even though they look pretty.

Why, what's wrong with them?

Thanks for a very informative comment!

[PaulDavisThe1st]

There are egregious DSP errors, including zipper noise and flat-out incorrect EQ-ing, plus they are one of the most reliable sources of crashes for Ardour users (at least). There are better alternatives even just within libre-space for everything that CALF does (they do, however, look very nice).

[wastholm]

Thanks, I'll keep this in mind. (I have given some Calf plugins some light usage in Qtractor without noticing any obvious problems.)

[wwweston]

Thanks for the generous and informative response!