Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meadowlark, a DAW written in Rust

github.com

Post reply on HN
Print view View original

101–110 of 124 posts

Re: Meadowlark, a DAW written in Rust

#101

Post by BillyDM »

PaulDavisThe1st wrote: post #89
ironmagma wrote: post #72

Earlier quoted context omitted.

There’s a comment like this on every post ending in “written in Rust.” The people who care about this include people who follow the development of the Rust ecosystem because it’s a sign of how capable the ecosystem is becoming.

Here's a list of the libraries we use in the Ardour project. Let me know how the, what is it, "crate" situation is for these or equivalent libraries: atk, atkmm, aubio, autoconf, automake, bison, boost, cairo , cairo , cairomm, cmake, cppunit, curl, expat, fftw, flac, flex, fontconfig, freetype, gdk-pixbuf, gettext, glib, glibmm, gnome-common, gnome-doc-utils, gobject-introspection, gtk-doc, gtk-engines, gtk+ X, gtk+…

That is a great question. While I'm not going through all the dependencies, I can give a brief overview.

First off, a lot the crates we use are actually just bindings or abstractions over these essential parts such as os-specific windowing stuff. Winit and Glutin are the main examples.

For OS audio stuff, there is cpal, but we found that the way it's designed is not the best for a DAW (no duplex support or MIDI). We may end up creating our own solution under the rusty-daw-io repo, although someone is also looking into creating bindings to RTAudio.

We are using femtovg in place of cairo. The developer of our GUI library is also working on improving the text layout and shaping inside femtovg.

We are using Symphonia for decoding audio files (although we may end up binding to ffmpeg if it doesn't work out).

We aren't using any networking in mvp, but there is no shortage of networking crates in rust.

We will also likely use bindings to libsamplerate if we find that a native Rust one is not good enough.

I don't recognize a lot of those dependencies. If there is a crucial one I missed, please let me know!

Of course some would point out why use Rust if you are using so many non-Rust dependencies? That is a fair argument. Me and my team just really prefer writing in Rust, so we are willing to put in the extra effort of using bindings.

Re: Meadowlark, a DAW written in Rust

#102

Post by ironmagma »

PaulDavisThe1st wrote: post #98
ironmagma wrote: post #96

Earlier quoted context omitted.

Or just generating bindings for it. Bindgen exists for this reason. A minority of libraries such as that will require a smarter wrapper but for most it is probably sufficient to just use it in a reasonable way.

...sure. But then you start to lose one of the most talked-up benefits of Rust, "safety". Or am I missing something?

Wins are often incremental. It's much better to start with the potential of guaranteed safety, sidestepped by a manual (opt-in) sacrifice of it in favor of getting something working, and slowly chipping away at the unsafety over time; than to start with the dispensation of safety as an institution altogether (C/C++) and hope that someday you can work your way to safety.

Put another way, as a developer, I'd much rather be part of a project using a language that is safe by default, which opts in to the unsafety it needs yet which hopes to someday simply remove all the `unsafe` keywords, than one that hopes to stumble its way to safety through relentless trial and error, testing, bug reports, debugging, etc. and has no actual measure of its level of safety.

On top of that, if you only use, say 10% of one of those libraries, you can easily wrap the 10% of that library in a safe fashion instead of waiting for 100% of the library to have its own safe wrapper.

Re: Meadowlark, a DAW written in Rust

#103

Post by BillyDM »

PaulDavisThe1st wrote: post #99
BillyDM wrote: post #95

Earlier quoted context omitted.

You do bring up some great points. Yeah, I guess it is still FLOSS. It's just my personal opinion that having a paywall (or the appearence of one) for the majority of your users is a huge barrier to success and openness, no matter how small that paywall is. Not that it's a bad business model, it's just one that I don't want to use for my projects. I don't want to sound like I'm downplaying the acheivements of Ardour.…

> Ardour isn't quite my cup of tea. I personally want to create something with a workflow akin to Live/Bitwig/FL. https://www.youtube.com/watch?v=EiwUN7hz6eU Scene launching started working yesterday (on top of clip launching). All of our music audio time conversion stuff now lives in its own library, called temporal https://github.com/Ardour/ardour/tree/master/libs/temporal It's likely that there will be a wholesale…

Oooh, that clip launching stuff looks nifty! I'll have to try it out.

I'll also take a look at temporal. You definitely have a point when it comes to avoiding mistakes of the past. Your help and guidance is appreciated!

Re: Meadowlark, a DAW written in Rust

#104

Post by bambax »

PaulDavisThe1st wrote: post #88
ZoomZoomZoom wrote: post #65

Earlier quoted context omitted.

Of course it's not dominant by the market share, but it's the most powerful tool and it would be cool to have a healthy competition there. Reaper also has a vibrant community of scripters and their skills would be of some help for any free software DAW. The reasons are the risk of it being sold (unlikely) or, y'know, a "bus factor". I have a huge respect for Ardour and its devs a lot, but unfortunately it's not even…

Ardour currently makes more than $200k per year. Harrison Mixbus is a distinct product from that. I never wanted to step down. There was a brief interval when it looked as if I would have to, in order to make a living. That has not been the case for more than a decade now. We have many users who have used many other DAWs, including Reaper. A good chunk of them strongly prefer Ardour to Reaper. Another good chunk do n…

> It doesn't even get into the modulation ballpark that Bitwig is playing in

I don't know if that's true. You can do a lot of modulation in Reaper directly, by chaining native LFOs or other modulation sources.

Bitwig's UI is incredibly sexy and beautiful, and Reaper is kind of ugly and crude, yes. That makes it easier in Bitwig to just see what's happening, whereas in Reaper you have to hunt down inside effects' parameters. I think that's the main difference.

But I don't think there are things you can do in Bitwig that you can't do in Reaper for a comparable amount of work. I'm not proficient in Bitwig, though. I would enjoy to see some comparisons.

Re: Meadowlark, a DAW written in Rust

#105

Post by BillyDM »

BillyDM wrote: post #76

Alright, the main developer of Meadowlark here. Let me answer some concerns I see in the comments. * edit - To make it clear, neither I or anyone on my team made this post in HN * First off, it's always great to see the growing interest in this project! I know it's very ambitious, but it will never happen if someone doesn't try, right? Second, yes the design doc is just for the MVP product, not a fully-featured DAW.…

Thinking about it some more, it might be more accurate to call it a "proof of concept" rather than MVP.

Re: Meadowlark, a DAW written in Rust

#106

Post by tialaramex »

PaulDavisThe1st wrote: post #91
tialaramex wrote: post #29

Earlier quoted context omitted.

One nice thing about Rust is that there's an excellent chance you can actually modify this code. That's enormously important for anybody who has even modest programming skills. For Free Software projects it's often under-estimated how much contribution you can get from the long tail of people who've got one small change they'd like to make. IF they can make the change. Otherwise you miss out. Let's give two extreme e…

> One nice thing about Rust is that there's an excellent chance you can actually modify this code. Chance of a random user being able to modify compilable code inside a DAW: essentially zero. Effect of language choice: essentially zero. Real time code; threads; pure "classic" MVC; custom widgets everywhere; non-standard keybinding mechanisms; topological sorting; insanely complex effects of latency on the meaning of…

I guess I have to disagree Paul, even though of course you're the one with practical experience in this specific niche since I didn't write a DAW from scratch.

Since you compared it to a web browser maybe it's instructive to remember that a big reason Rust had initial traction was that Mozilla had tried, and failed more than once to make key improvements to some of the browser's thorniest concurrent code in C++ but using Rust made this practical at last.

C++ is horrible and I think you're under-estimating just how much difference that makes in this scenario for something like Ardour.

Re: Meadowlark, a DAW written in Rust

#107

Post by PaulDavisThe1st »

tialaramex wrote: post #106
PaulDavisThe1st wrote: post #91

Earlier quoted context omitted.

> One nice thing about Rust is that there's an excellent chance you can actually modify this code. Chance of a random user being able to modify compilable code inside a DAW: essentially zero. Effect of language choice: essentially zero. Real time code; threads; pure "classic" MVC; custom widgets everywhere; non-standard keybinding mechanisms; topological sorting; insanely complex effects of latency on the meaning of…

I guess I have to disagree Paul, even though of course you're the one with practical experience in this specific niche since I didn't write a DAW from scratch. Since you compared it to a web browser maybe it's instructive to remember that a big reason Rust had initial traction was that Mozilla had tried, and failed more than once to make key improvements to some of the browser's thorniest concurrent code in C++ but u…

The thing is, something like Ardour doesn't need "key improvements to some of [our] thorniest concurrent code in C++". We're in good shape there (perhaps because the requirement that most of our concurrent code has to fit in with RT requirements pushed us to do better design work there).

We need to people more than anything to do workflow stuff (mostly GUI).

Some years ago, I did several talks where I touted the idea that us adding a web interface to Ardour, so the generation raised on the idea that programming means HTML+CSS+JS could go to town and do new cool things (or at least, create new "cool" UIs).

We've failed/chosen not to publicize the fact that we have a web interface now, but my position on this has changed. I was wrong about the web interface. I just don't think we're going to get significant numbers of new contributors no matter what language or development environment they could use. We have on the order of 100 contributors already, and I think that if we ever got to 200, it would be a miracle. Even 25 new contributors would be a change in our developer resources that would be game-changing.

Re: Meadowlark, a DAW written in Rust

#108

Post by PaulDavisThe1st »

BillyDM wrote: post #101
PaulDavisThe1st wrote: post #89

Earlier quoted context omitted.

Here's a list of the libraries we use in the Ardour project. Let me know how the, what is it, "crate" situation is for these or equivalent libraries: atk, atkmm, aubio, autoconf, automake, bison, boost, cairo , cairo , cairomm, cmake, cppunit, curl, expat, fftw, flac, flex, fontconfig, freetype, gdk-pixbuf, gettext, glib, glibmm, gnome-common, gnome-doc-utils, gobject-introspection, gtk-doc, gtk-engines, gtk+ X, gtk+…

That is a great question. While I'm not going through all the dependencies, I can give a brief overview. First off, a lot the crates we use are actually just bindings or abstractions over these essential parts such as os-specific windowing stuff. Winit and Glutin are the main examples. For OS audio stuff, there is cpal, but we found that the way it's designed is not the best for a DAW (no duplex support or MIDI). We…

A large chunk of those libraries come the depstack of our GUI library (GTKmm). Pango, Harfbuzz etc. are all just dependencies for the GUI library, but also our own Canvas library (we had to write our own, since nothing out there came close to requirements; the Canvas is heavily Cairo-based but could fairly trivially be ported to any 2D drawing API).

More DSP-y/audio-centric libraries would include:

  fftw - fastest fourier transform in the west
  rubberband - the only open source stretcher worth using (though we do have code to use soundtouch also)
  lilv,serd,sord,sratom,suil - LV2 infrastructure
  vamp-plugin-sdk - for offline (non-realtime) audio analysis
  aubio - used by VAMP
  liblo - almost certainly the best FLOSS OSC library
We created our own audio/MIDI I/O abstraction initially based on JACK (which was initially based on Ardour :). The Windows version uses PortAudio which has its pros and cons; the macOS version directly uses CoreAudio; the Linux version directly uses ALSA (and then there is a separate cross-platform JACK one too).

Re: Meadowlark, a DAW written in Rust

#109

Post by goblinkingmatt »

romwell wrote: post #30
royjacobs wrote: post #8

Earlier quoted context omitted.

The document states this is a non-goal for the MVP, not a non-goal for the final product.

"Ability to make turns is a non-goal for the MVP of the car we're building" You can't record a cover of Queen's We Are The Champions or Somebody To Love without struggling with the UI if 3/4 is not supported. Or Blondie's Call Me. Or a plethora of other popular music. "Fully Featured (in our imagination)"

why couldn't you record Call Me?

Re: Meadowlark, a DAW written in Rust

#110

Post by PaulDavisThe1st »

bambax wrote: post #104
PaulDavisThe1st wrote: post #88

Earlier quoted context omitted.

Ardour currently makes more than $200k per year. Harrison Mixbus is a distinct product from that. I never wanted to step down. There was a brief interval when it looked as if I would have to, in order to make a living. That has not been the case for more than a decade now. We have many users who have used many other DAWs, including Reaper. A good chunk of them strongly prefer Ardour to Reaper. Another good chunk do n…

> It doesn't even get into the modulation ballpark that Bitwig is playing in I don't know if that's true. You can do a lot of modulation in Reaper directly, by chaining native LFOs or other modulation sources. Bitwig's UI is incredibly sexy and beautiful, and Reaper is kind of ugly and crude, yes. That makes it easier in Bitwig to just see what's happening, whereas in Reaper you have to hunt down inside effects' para…

You can't do clip launching in Reaper.

In Bitwig, almost any parameter of anything is both a modulation source and destination. This is not true in Reaper.

Post reply on HN