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

91–100 of 124 posts

Re: Meadowlark, a DAW written in Rust

#91

Post by PaulDavisThe1st »

tialaramex wrote: post #29
mpfundstein wrote: post #9

"proudly written in Rust" ... what is it with this Rust guys? lol but locks cool. are there actual screenshot available? the notes editor looks fun. loved the one from fruity loops A LOT (awesome profram)

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 "time"; temporal representation ... these are just a few of the major conceptual features someone tends to need to understand to go delving around inside a DAW. Things are roughly as complex as a modern web browser, except plus the realtime component.

I wrote some thoughts down (and gots lots of comments) regarding open source vs. scripting here: https://discourse.ardour.org/t/is-open-source-a-diversion-fr...

Re: Meadowlark, a DAW written in Rust

#92

Post by ironmagma »

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+…

I don't know, but it's hardly as interesting as whether someone can create a full cross-platform GUI using the ecosystem. Just a year ago the support for that was next-to-nonexistent.

Re: Meadowlark, a DAW written in Rust

#93

Post by PaulDavisThe1st »

ironmagma wrote: post #92
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+…

I don't know, but it's hardly as interesting as whether someone can create a full cross-platform GUI using the ecosystem. Just a year ago the support for that was next-to-nonexistent.

My point is that for large-scale software like a DAW, you either need a LOT more than a cross-platform GUI, or you will be reimplementing a very very large body of code that has existed in FLOSS form (but other languages) for (in some cases) decades.

Re: Meadowlark, a DAW written in Rust

#94

Post by royjacobs »

romwell wrote: post #90
royjacobs wrote: post #82

Earlier quoted context omitted.

I'm not sure why the amount of audio production experience is relevant in this case. I also don't have a horse in this race. I just find it curious that you seem to be so extremely passionate about taking a random item in a _design_ for an _MVP_ and drawing all sorts of conclusions about both the tool and the authors of this tool. Why does it matter so much that it doesn't align with what you find the most important…

TL;DR: you don't have experience in the subject you opine on, but wonder why someone who does would. I'll address these points below. --------- >I'm not sure why the amount of audio production experience is relevant in this case. Because that's what would make you qualified to have an opinion on the matter, or make an analogy. If you don't use a DAW regularly to make music, you are not qualified to say that lack of 3…

If you don't want to see development effort wasted I hope you'll contribute to the project. I'm sure the authors will applaud and enjoy your passion.

>Well I'm not posting my songs on HackerNews in a post saying "Background Music To Write Code To: By Programmers, For Programmers".

Neither were the authors of the DAW, someone else posted it using this title.

(btw I do have plenty of experience using DAWs (going back to Notator on the Atari ST) and have been an amateur musician since childhood. I just don't see how it's relevant in a discussion about an aspirational MVP design. Thanks for assuming the worst, though!)

Re: Meadowlark, a DAW written in Rust

#95

Post by BillyDM »

PaulDavisThe1st wrote: post #86
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.…

Ardour author here. > it's also not truly FLOSS as it requires a paid license to download the binaries, (same for Ardour on non-Linux systems)). This does not stop something being FLOSS. The GPL that we release Ardour under is 100% consistent with charging money for a ready-to-run version. And we even actively encourage people who have problems doing that to get a copy from a friend. There is nothing in any FLOSS lic…

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. It is definitely impressive, and I look forward to the MIDI workflow improvements! It's just from a workflow perspective (especially from an EDM perspective), Ardour isn't quite my cup of tea. I personally want to create something with a workflow akin to Live/Bitwig/FL.

Yeah, your article on time keeping was a huge inspiration in our time-keeping system. We would definitely love your feedback on this! Currently I've designed it in such a way where we can easily swap out the actual internals of the `MusicalTime` struct if we find that f64 is not good enough. I'm aware it will indeed be a challenge when it comes time to support automation of tempo, time signatures, swing rythm, etc. That's why I seperated it into its own repo to keep it focused on the pure algorithm. (The repo is in rusty-daw-timeline btw).

Re: Meadowlark, a DAW written in Rust

#96

Post by ironmagma »

PaulDavisThe1st wrote: post #93
ironmagma wrote: post #92

Earlier quoted context omitted.

I don't know, but it's hardly as interesting as whether someone can create a full cross-platform GUI using the ecosystem. Just a year ago the support for that was next-to-nonexistent.

My point is that for large-scale software like a DAW, you either need a LOT more than a cross-platform GUI, or you will be reimplementing a very very large body of code that has existed in FLOSS form (but other languages) for (in some cases) decades.

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.

Re: Meadowlark, a DAW written in Rust

#97

Post by romwell »

royjacobs wrote: post #94
romwell wrote: post #90

Earlier quoted context omitted.

TL;DR: you don't have experience in the subject you opine on, but wonder why someone who does would. I'll address these points below. --------- >I'm not sure why the amount of audio production experience is relevant in this case. Because that's what would make you qualified to have an opinion on the matter, or make an analogy. If you don't use a DAW regularly to make music, you are not qualified to say that lack of 3…

If you don't want to see development effort wasted I hope you'll contribute to the project. I'm sure the authors will applaud and enjoy your passion. >Well I'm not posting my songs on HackerNews in a post saying "Background Music To Write Code To: By Programmers, For Programmers". Neither were the authors of the DAW, someone else posted it using this title. (btw I do have plenty of experience using DAWs (going back t…

>I do have plenty of experience using DAWs

Great! Made any music in 6/8, or signatures other than 4/4?

That was supported in Notator back in 1990 (along with time signature changes mid-track IIRC).

>I just don't see how it's relevant

I specifically said why, right at the top of my response.

>If you don't want to see development effort wasted I hope you'll contribute to the project

A tempting idea, putting it on my list. See, there's value in these discussions!

Re: Meadowlark, a DAW written in Rust

#98

Post by PaulDavisThe1st »

ironmagma wrote: post #96
PaulDavisThe1st wrote: post #93

Earlier quoted context omitted.

My point is that for large-scale software like a DAW, you either need a LOT more than a cross-platform GUI, or you will be reimplementing a very very large body of code that has existed in FLOSS form (but other languages) for (in some cases) decades.

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?

Re: Meadowlark, a DAW written in Rust

#99

Post by PaulDavisThe1st »

BillyDM wrote: post #95
PaulDavisThe1st wrote: post #86

Earlier quoted context omitted.

Ardour author here. > it's also not truly FLOSS as it requires a paid license to download the binaries, (same for Ardour on non-Linux systems)). This does not stop something being FLOSS. The GPL that we release Ardour under is 100% consistent with charging money for a ready-to-run version. And we even actively encourage people who have problems doing that to get a copy from a friend. There is nothing in any FLOSS lic…

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 musicaudio 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 renaming of data types in here, because "int62_t" is a little too generic, and at least one of our long term devs is strongly against builtin-like names (eg. timepos_t) for things that are actually our own objects.

Re: Meadowlark, a DAW written in Rust

#100

Post by glowcoil »

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?

You are missing something. For a piece of Rust software to run in any widely used computing environment, it is required to interface with a large body of non-Rust software via a non-typechecked ABI. Moreover, the Rust standard library itself contains many, many instances of the unsafe keyword. The benefits of Rust safety do not come from building a hermetically isolated tower of pure safe Rust code from the ground up, and those benefits do not become null and void the moment you include one C library used via FFI.

Rust safety is about being able to take an unsafe component, encapsulate its implementation details, and encode sound usage patterns for that component in a public API which can then be statically checked by the compiler. This allows the difficult problem of determining whether an entire codebase is sound, memory-safe, and free of undefined behavior to be factored into many smaller, more tractable problems of verifying that individual components are sound given their APIs. You can even do this with wrappers and bindings to C libraries, and there are many examples of this in the Rust ecosystem.

Post reply on HN