Is libsoundio a dead project now? I just checked in on the repo. Minimal activity.

The creator of libsoundio went on to make Zig, which I'm sure is taking up most of their time now.

I can still remember the initial release of libsoundio. It was a pre-zig project. I was made aware of the dev because they were working on a DAW from scratch called Genesis. This is definitely now an abandoned project.

Show thread

I think it's very telling that a programmer talented to build a systems programming language (that other people actually use!) gave up on building a DAW.

Show thread

It's a draining and thankless job building a DAW. You've got all the considerations that go into GUI app development, but then there's all the custom DAW-specific UI elements you need like piano rolls and junk.

THEN you gotta get things like audio/MIDI working, and you're going to want to make it cross platform. And it's usually realtime, so that's a consideration. Oh! But you also need to bounce this to a WAV file quickly.

And then there are all the third-party plugin formats and standards to support.

And so, so, much more.

Show thread

DAWs are kind of like web browsers in that it's pretty much impossible for a grassroots effort to compete with well-established commercial tools that have been around for decades (ProTools, Ableton Live, FL Studio, etc) built by full-time teams.

It's not, however, outside the realm of possibility to build compelling music software. It just can't be what we think of as a digital audio workstation.

Show thread
Follow

For those crazy enough to try:

Don't build a workstation, build an ecosystem.

Scope aggressively and specialize. Learn to say no. Less is more.

GUIs are a black hole of productivity, don't sucked into them.

Make sure offline rendering happens on day one.

Do NOT multi-thread the audio rendering component.

Choose standards you intend to support very, very carefully.

Question every DAW design pattern or paradigm. Don't ever do anything by default.

Make sure everything can work headless or without a GUI.

Emphasize extendability. When in doubt, just build a canvas.

Manage your dependencies. Don't go crazy with packages.

@sigrid Just do the exact opposite of LMMS, and you should be good.

@fiadh @sigrid In a nutshell: It has a poorly designed audio engine, and a community that won't do anything to fix it. The original creator of LMMS left years ago to do other things, and I think they've been struggling with leadership ever since. Everything constantly seems to be in gridlock over there and so nothing gets done.

LMMS also actually happens to do the exact opposite of almost everything in that list:

All-in-one monolithic DAW.

Exponentially growing list of features.

Has a fixation on making things LOOK good, rather than sound good.

Audio engine makes heavy use of threads (QT threads too!).

Offline rendering doesn't work well at all... it's clear realtime audio was implemented first.

Supports a large number of plugin formats, including a number of poorly implemented non-free ones that use WINE.

Very little support for third-party LMMS plugins. It's possible in a hacky way (I've done it), but not really encouraged either.

There's a ton of optional features that require external libraries, and relies on CMake to check to see if those libraries exist. (And of course, every system has the library paths perfectly tuned to work with CMake, right?) Also, QT is a hard dep, which is quite heavy.

@paul I feel like a lot of this can be applied to anyone undertaking a software tool, not just DAWs. Well said!

@the_gayest_doggo JACK encourages ecosystems, so it definitely goes with the grain of what I'm getting at.

Sign in to participate in the conversation
post.lurk.org

Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that.