[Lucasoato]

I'm a software developer right now but I've worked with DAWs as a producer for more than 5 years. You can't even imagine how frustrating is working with Digital Audio Workstation. One messy plug-in and you can lose hours and hours of work. Preset management is a nightmare, there are so many things that they could do to go forward, but the Sequencer market is stall and hasn't moved in years.

Imagine if they applied something similar to a git versioning system to music projects.... I don't even know if the VST interface can be used or if it's licensed somehow from Steinberg.

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...

No plug-in or DAW has a CLI... I could go on for hours...

I'm doing some digital audio processing for a startup idea and the only thing I've came up with is using sox trough a Python API.

[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.

[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.

[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 ?

[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.

[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!

[_qbjt]

> 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...

ASIO, really? Sorry but you couldn’t pay me to go back to that broken piece of crap after switching to Linux and JACK2. I’m actually traumatized by that piece of software, thinking of moments where ASIO would just break and cause my Live session to collapse into a glitchy cacophony of latency-induced noise. I’ve seen this happen on several computers with different Windows installations and external audio hardware and the problem always ends up being ASIO. Some of the producers I knew swore off anything that wasn’t a Mac because of this exact problem.

The problem with audio production on Linux in 2021 isn’t the audio protocol. It’s that most free and open source audio production software for Linux is dreadful to use. UX is actually very important for DAWs. I want to like Ardour but it’s a miserable piece of software to try to make music in. Feels like a chore to perform any action, kills my vibe, would not recommend. After trying really hard to become comfortable using it, I finally gave up and bought Bitwig. It’s a proprietary DAW and kinda expensive but I’ve been producing music with it for a couple of years and it’s a dream to use - sort of a spiritual successor to Ableton IMO.

> No plug-in or DAW has a CLI…

Most people who make music don’t care about this. I’m a software developer and musician who only uses Linux and I don’t care about this. In my opinion, Linux developers of free and open source creative software should spend less time building these features for other developers and focus more on making their software feel good to create with. If I feel bad trying to use your clunky-ass UI to make my art / music / whatever then I’m not going to hold myself back because it has a free software license. I’m going to find a piece of software that gets out of the way and lets me make what I want to make.

[PaulDavisThe1st]

> I want to like Ardour but it’s a miserable piece of software to try to make music in. Feels like a chore to perform any action, kills my vibe, would not recommend. After trying really hard to become comfortable using it, I finally gave up and bought Bitwig. It’s a proprietary DAW and kinda expensive but I’ve been producing music with it for a couple of years and it’s a dream to use - sort of a spiritual successor to Ableton IMO.

As I've mentioned above, I get all kinds of email about Ardour, some declaring their love for it, and some much more condemnatory than anything you've said here.

The point is that "trying to make music" isn't much of a description: people's workflows for "making music" vary dramatically. Not many years ago, more or less the only way to do this was to record yourself playing one or more instruments and/or singing. These days, there are many fundamentally different workflows, and countless minor variations of each one. If Bitwig works for you, it's no surprise that Ardour doesn't. There's a bunch of people for whom the opposite is true. You have to be prepared to try different tools and figure out which ones work for you.

Finally, ASIO and JACK don't really at the same level. JACK on Windows actually uses ASIO. The comparison to ASIO on Linux is ALSA, and sure, I'd agree that it's better than ASIO is most ways (though maybe not 100%).

[_qbjt]

> The point is that "trying to make music" isn't much of a description: people's workflows for "making music" vary dramatically. Not many years ago, more or less the only way to do this was to record yourself playing one or more instruments and/or singing. These days, there are many fundamentally different workflows, and countless minor variations of each one.

Excellent point and apologies if that comment came across as inflammatory. I really respect the work you and the Ardour team have done even if it's not for me (and infinite thanks for your work on JACK, it truly is a special piece of software). My frustration has more to do with there not being a FOSS DAW that gives me that true Ableton-like experience. I understand why though, this stuff is hard to build and one workflow does not fit all as you point out.

[thefr0g]

Ardour is really great for recording and mixing. For a more "contemporary" workflow you might want to try zrythm¹, it's getting better and better. (I still use Bitwig though…) If you exclusively make electronic music you could also look into LMMS², it's more of an electronic-music-toy than an actual DAW but thats not necessarily a bad thing.

¹ https://www.zrythm.org/en/explore.html ² https://lmms.io/

[_qbjt]

> For a more "contemporary" workflow you might want to try zrythm¹, it's getting better and better.

Oh wow, Zrythm looks awesome! Thank you for the suggestion, I'll be taking this DAW for a spin sometime soon. :)

> Ardour is really great for recording and mixing.

Yeah, I'm actually warming up to Ardour as a general mix & mastering environment. It reminds me of Logic Pro in that sense, being more suited for final touches than composition (in my personal workflow).

> If you exclusively make electronic music you could also look into LMMS², it's more of an electronic-music-toy than an actual DAW but thats not necessarily a bad thing.

How is LMMS these days? I tried it sometime last year and had a lot of fun but it crashed too much for my personal comfort (tbf that could have just been whatever buggy LV2 / VST plugins I was testing). It comes a bit closer to the "look and feel" I look for in a DAW - kinda reminds me of older versions of FL Studio which is kewl because that's the software I learned how to produce music on.

[jefftk]

>> No plug-in or DAW has a CLI

> I’m a software developer and musician who only uses Linux and I don’t care about this.

I am a software developer and musician who uses Linux and I do care about this. I run headless, and control my audio software through custom logic and hardware while playing live. I ended up writing a custom synthesizer and see because I couldn't find anything that works well for my use case

(I'm still open to something else; my synth doesn't sound very good. Designing custom sounds is not something I'm great at or something where I really want to focus.)

[PaulDavisThe1st]

You can run Ardour headless and control it 100% using OSC (from the command line, with oscsend, or from a touch device (phone/tablet) using eg. TouchOSC). You could also get significant but not as extensive control using MIDI.

[_qbjt]

> I am a software developer and musician who uses Linux and I do care about this. I run headless, and control my audio software through custom logic and hardware while playing live. I ended up writing a custom synthesizer and see because I couldn't find anything that works well for my use case

That's pretty cool. Most modern DAWs allow you to define per-controller triggers for custom logic in the form of MIDI events. I guess you could write a CLI that maps custom commands to MIDI events and allows you to send those events to your DAW when they are called. It's not exactly what you're describing (and maybe it doesn't fit your use case) but is that something you've considered?

[nprateem]

There will always be tinkerers who write their own synths. Everyone else just uses serum or whatever and makes music.

[stinos]

ASIO, really?

Havng had zero problems with this (already many years ago, in the days where getting low latency on linux was extremely hard) on a variety of machines but all with pretty decent cards is it possible that the problem has nothing to do with ASIO but rather with crappy drivers / manufacturers? Or perhaps you just had bad luck?

[sasaf5]

JACK2? Sorry my ignorance, it's been a while I abandoned Linux audio for Ableton on Windows with a focusrite Scarlet. Did they solve that JACK/alsa problem? Without running a2j in the background?

[lavabiopsy]

Which problem are you referring to? a2jmidi should work fine as long as you have access to the device. But in any case that should not be necessary anymore if you use pipewire, which should be able to manage all the devices at once.

[sasaf5]

The problem was that extra a2jmidi hoop adding a lot of friction to my creative process. Also I wanted to keep it on indefinitely to use it as an instrument, and a2jmidi would crash after a few days.

Also there was the night spent recompiling the right version of bison in the middle of Qsampler's dependency hell, so that I could have a piano sound. That was all in 2017.

[lavabiopsy]

I'm not sure what you mean extra hoop? You just start a2jmidi and then connect the device. Crashes would indeed be an issue, generally if you want to mitigate those, you would want to:

- Auto restart any important services (with systemd or similar)

- Use JACK/Pipewire session management

- Report the crash to the developers (of a2jmidi in this case, but it could be anything)

I honestly have never used LinuxSampler so I can't comment on that, I believe they have some strange licensing thing going on.

[PaulDavisThe1st]

The extra hoop is having to start a2jmidi and have the ports not be as "integrated" into the JACK server ports as they could be.

By contrast, JACK1 contains a2jmidid as a builtin client, no extra work is needed. You just start JACK, all your MIDI devices are listed.

[_qbjt]

I don't run a2j or even have it installed so in my case it doesn't seem to be a problem. My audio production setup isn't highly complex FWIW but with the following configuration I have had no issues with audio or MIDI input and output. All of my devices are just plug-and-play for both Bitwig and qjackctl:

- Distro: Arch Linux

- Audio backend: JACK2 and PipeWire

- USB Audio Interface: Behringer U-Phoria UMC404HD

- USB controllers: Akai APC 40 mkii, Casio CTK-6200

- Microphone: Zoom H6

I run this exact setup on my Ryzen desktop and a Thinkpad T480 with no problems. I've also tried routing the audio output of various software directly into my DAW using qjackctl, works perfectly fine.

[container]

I kind of dropped out of Linux audiosome time ago. Can I ask why both pipewire and jack? I thought pipewire was supposed to implement most (all?) the stuff that jackd does.

[_qbjt]

Sorry, looking back at my wording I can see how that's confusing. You are correct. PipeWire replaces the standard JACK libraries with its own ABI-compatible implementations. This allows any JACK-compatible application to support audio through PipeWire using the same APIs it would normally use for JACK. This is also how PipeWire handles support for PulseAudio, ALSA and other multimedia libraries; it kinda reminds me of Wine for Linux audio protocols, if my understanding is correct anyway.

To use PipeWire in place of JACK, you have to install a specific package (`pipewire-jack` on Arch Linux) and run all of your audio applications using a wrapper command called `pw-jack`. You can update the `.desktop` entries for audio software on your system to automatically run this command; I've done that and everything I use launches correctly, tbh I forget that PipeWire is there. I just use Bitwig, qjackctl, Catia, etc. and they all think they're using JACK but really everything is being handled by PipeWire. Pretty kewl and it's been working perfectly for me for quite some time. :)

[rudenoise]

Things to check:

For audio on linux: https://pipewire.org/

For a more code oriented audio workflow (python lib to load VST and AU) https://github.com/spotify/pedalboard

[PaulDavisThe1st]

Pipewire is a layer above most of the really important stuff.

Pedalboard is also not a realtime audio environment (as was clarified by one of its developers here on the HN thread last week). In that sense it is extremely different from Bespoke (and nearly everything else).

[pandakar]

For you pythonheads, please check out Olivier's wonderful pyo https://github.com/belangeo/pyo

[Lucasoato]

I'll never thank you enough for linking pedalboard... That's exactly what I've always needed lol

[gregsadetsky]

It was posted here less than a week ago too!

https://news.ycombinator.com/item?id=28458930

[xbpx]

Since you're a software dev you may have explored supercollider and other environments where you can employ great tools. I've been looking for a hybrid UI/UX + Audio programming environment that would combine the freedom of code with the visual cues of a DAW but haven't found the ideal fit. So far I've been rolling my own with cl-collider, a common lisp client for Supercollider which uses some lisp tricks (macros) to good effect.

[sharklazer]

Been using DAWs for 20 years now. Of course they aren’t changing... what even should change? They work, and do what they’re supposed to.

Most plugins these days are stable, and don’t crash. I haven’t had issues in like 10 years honestly. At least if you’re paying for them from groups who have a reputation.

Git for a music project would be detrimental, going to be really honest.

Linux can run things just fine. JACK has been a relatively stable audio platform. RT pre-emption can help. The only issue with Linux I see is software support. But with Apple making some less than stellar choices, I expect linux to become more important to the daw/digital recording ecosystem

One fantastic one that does work well on linux (reaper) also has a scripting interface. Not a CLI but actually more useful.

[tomduncalf]

> One messy plug-in and you can lose hours and hours of work

If you’re meaning from crashes, Bitwig has configurable levels of process isolation for plugins - I guess the trade off is performance, I haven’t tested it out so can’t comment on how well it works.

[scns]

Try Bitwig, plugins will crash on their own there. It even runs on Linux.

[grishka]

> One messy plug-in and you can lose hours and hours of work.

What if you run each plugin in a separate process, or does IPC add too much overhead or not provide enough bandwidth for this to be feasible?

[PaulDavisThe1st]

Although we are still debating with some smart people about this (since actual measurements call it into question), this was our (Ardour dev team's) take on this question:

https://ardour.org/plugins-in-process.html

[grishka]

The answer is "too much overhead" but the overhead isn't coming from where I assumed it would. I thought it could be too expensive to pass the required amount of data through the kernel (at least 48000 samples per track per second), but that's not the problem, it turns out it's the context switches. Huh.

edit: I now also remembered that virtual memory is a thing and you can share a chunk of physical memory between processes to avoid the need to copy anything at all.

[jacquesm]

Context switches on Linux are a pretty heavy affair, this is the result of some choices in the distant past when the number of context switches per second was much higher than on most other platforms and so it was deemed to be 'good enough'. Unfortunately this rules out a lot of real time or near real time work, especially when the workload is divided over multiple user space processes.

[PaulDavisThe1st]

A citation is required for this claim.

I know of no evidence that Linux context switching on x86/x86_64 is slower than any other OS, and some suggestions that it is faster (Linux does not save/restore FP state, which Windows (at least at one point) does).

Linux is as capable or more capable of realtime work than any other general purpose OS, and the latency numbers from actual measurement are excellent (when using RT_PREEMPT etc).

What are you referring to?

[jacquesm]

Back in the day when the Linux kernel was first written there was a huge argument between Linus and Andrew Tanenbaum about whether or not the micro or macro kernel road was the superior one.

Tanenbaum argued that a microkernel was lighter, and could switch context faster than a macrokernel (the likes of which UNIX was typically reincarnated with). Linus argued that throughput, not latency is what matters to end users. At that time your typical OS switched tasks 18.5 times per second and Linux did substantially better than that. Case closed, the throughput argument won.

But now, many years later the consequences of that mean that we are switching contexts orders of magnitude slower than we could have because the context contains a lot more information than it strictly speaking has to. My own QnX clone switched 10K / second on a 486/33, and yes, the IPC mechanism meant that throughput suffered but for real time applications with a lot of the hard stuff in userspace context switches are far more important than throughput (and incidentally, also for perceived responsiveness of the OS and apps).

The latency numbers are excellent from the perspective of very forgiving applications, a typical DAW runs with 1K or even larger sample buffers which is acceptable, but for many real time applications that is an eternity and so those are not typically built using Linux as the core but some dedicated RTOS.

edit: I had 100K / second before, this was in error. It's been 30 years ;)

[rhizome]

Sox was a significant player in a pipeline I wrote for a YouTube-y company 15 years ago. Worked well enough to (help) get the company acquired!

[Minor49er]

> No plug-in or DAW has a CLI

You might be interested in MrsWatson. Even though the development on it has been discontinued, there is still a lot of potential for its use:

http://teragonaudio.com/MrsWatson

[obiefernandez]

My holy grail project sounds like something you and I could collaborate on someday. Essentially a way to represent a DAW project in plain text so it can be versioned in Git and easy to collaborate on. Happy to discuss anytime [e-mail]