Live data from Hacker News

Meadowlark, a DAW written in Rust

github.com

81–90 of 124 posts

Re: Meadowlark, a DAW written in Rust

#81
post #22

Earlier quoted context omitted.

>Do love first class support for non 12-TET! Disappointing that it assumes octaves though. There are important scales without them, e.g: https://en.wikipedia.org/wiki/Bohlen%E2%80%93Pierce_scale https://en.wikipedia.org/wiki/Gamma_scale

You seem to have found a significant weak spot: apart from the dubious approach of rejecting MIDI, ignoring OSC and reinventing the wheel, the assumption of octaves is very gratuitous and a net complication. MIDI supports 127 different notes and it is the synthesizer's job to decide their pitch; likewise, a piano roll has a predefined set of notes, each with its own pitch. It's therefore very unfortunate that they de…

Also interesting. Of course I'm open to feedback. I feel that's one of the big purposes of a design document is to discuss the design decisions.

My idea was if the tuning called for it, it would just ignore the "octave" part and use the u16 to have 64K available pitches that can be used. The actual tuning map is sent to the plugins in a separate message.

Re: Meadowlark, a DAW written in Rust

#82
post #73

Earlier quoted context omitted.

"Including a rear parking sensor is a non-goal for the MVP of the car we're building" seems to be a closer analogy. If you cannot use the MVP of the software for your use cases, that doesn't mean it cannot be worthwhile for anyone else.

How is this a "closer" analogy? I motivated mine. The car without a parking sensor still gets you anywhere you want to go. This one only drives in straight lines, it's incapable of changing direction. There is a difference between "has a use case" and "fully-featured DAW". A wheelbarrow has use cases. It's not a car (and not a fully-featured one, at that). The decision to support non-12 tone equal temperament from th…

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 aspect of an MVP?

Again, this is even just a _design_ for an MVP. If it doesn't align with what _you_ find important then that's fine. Just use something else, you've clearly been doing so for about 15 years. I hope you've enjoyed working on your songs, just like the authors of Meadowlark are enjoying working on this DAW.

Re: Meadowlark, a DAW written in Rust

#83

from the design doc: >Non-Goals ... Non-4/4 time signatures and time signature changes ... Just curious from a software design perspective why this is the case. I would, naively, assume you build up software primitives that wouldn't assume a time signature, making it trivial to support whatever segmentation of time. Why not just have a pulse and divide it however is needed? Also I see nothing about OSC support, is th…

As the author of an open source DAW that already supports non-4/4 time ...

first of all, there are some annoying details to even get as far as the full scope of western metric notation. For example, compound time: 6/8 does not mean "6 eighth notes per bar", even though there's a growing body of DAW-trained young people who seem to think that it does.

But "worse" (harder, is perhaps a better phrase), dealing non-western concepts of meter requires moving beyond "just divide it however is needed". A relatively simple case would be music from the Balkan/Byzantine cultures, which are much better represented using a notation form like [ 3L + 2S + 3L ] ("3 long beats, 2 short beats, 3 long beats"). There is a great deal of music from around the world that uses this structure, and even if a western notation like 8/N migh theoretically capture this, it doesn't contain the information required to play it.

Moving to even harder metrical forms, Carnatic and Hindustani talas are always conceived on in their own cultures as rhythmic cycles that cannot be decomposed to simple western notation. Even teental, perhaps the most widespread and maybe the simplest, is not usefully representable using western time signatures (it consists of a cycle of 16 beats, where the timbre of the beats creates rhythmic motion and structure).

FWIW, I hope to add the [ N + M + P ] form to Ardour in the not (too) distant future.

Re: Meadowlark, a DAW written in Rust

#84
post #79
post #22

Earlier quoted context omitted.

>Do love first class support for non 12-TET! Disappointing that it assumes octaves though. There are important scales without them, e.g: https://en.wikipedia.org/wiki/Bohlen%E2%80%93Pierce_scale https://en.wikipedia.org/wiki/Gamma_scale

Interesting, I was not aware of any scales without octaves. I suppose a solution here could to just ignore the octave part by having only a "single" octave.

Not just somewhat arbitrarily invented scales from the west ... in Byzantine musical culture, they do not have or assume the concept of "octave equivalence". That is, doubling the frequency of a sound does not, in classical Byzantine music, constitute "the same note". Byzantine musical culture is wonderful in so many ways. They rarely notate pitches, preferring to notate intervals, which as anyone who has ever tranposed a song from one western major scale to another will understand, is far more of a deep representation of a melody than pitches.

Re: Meadowlark, a DAW written in Rust

#85
post #13

How is this titled "fully featured" when it's still in its early stages with very little code in the repository (and most of what is there looking like an exercise in software architecture)? Is the "it's in rust" hype so strong now that even a few lines of code covered in ambition are sufficient to make the front page of HN?

Yes, we (the Meadowlark team) did not make the this post in HN. It is definitely not "fully-featured" yet, we are still working on the MVP.

Most of the work done so far has been in the modular backend components that live under the RustyDAW GitHub organization, namely the audio graph repo: https://github.com/RustyDAW

Re: Meadowlark, a DAW written in Rust

#86
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 license that requires gratis access to pre-built binaries; anyone is free to get the source and build it themselves, if they are up for the task. Most DAW users are not interested in this, and we chose to use it as a way to help fund the last 10+ years of what is now a 21 year old project.

> Ardour is okay, but only if you don't mess with MIDI.

There are plenty of people using Ardour's MIDI very successfully, even if it remains true that our MIDI workflow could use some significant improvements. Version 7 will hopefully see a great deal of changes in this area, and it will be a primary focus of the early 7.x release series.

> Third, my plan in regard to time signature is to abstract away all the logic into the `https://github.com/RustyDAW/rusty-daw-timeline` repo. It's sole purpose it to be a black-box that takes a function of musical time (f64 of beats) and returns sample time (represented as i64), and vice versa.

Good luck. This is likely to be much, much harder to get right than you currently imagine. I made a few notes about the "new" system in Ardour here: https://ardour.org/timing.html Although some other DAWs do use float representation for time, our experience has been that it's a terrible idea. Fixed point is much easier to deal with.

In some ways, it's always nice and even a little exciting to see a new FLOSS (or even non-FLOSS DAW) starting up. On the other, it is a bit frustrating knowing how much developer time and brain power will have to go into getting to where Ardour was (say) 10 years ago rather than pushing existing projects (like Ardour) forward. Good luck!

Re: Meadowlark, a DAW written in Rust

#87

The design doc looks promising. I like the limits set on the scope, as a contemporary DAW is a monstrous program and it's impossible to implement all the bits simultaneously. I wish the project flourishes and attracts both users and developers. Reaper desperately needs a Free Software competitor, even an aspiring one! - Are there any plans to have some user-facing API for plugins/scripting? Professional workflows var…

manage complex routing schemes for your projects just dragging nodes and noodles. 100%. I want something that combines the multitrack timeline of ACID with the MIDI, control, and audio routing of a virtual modular synth or console.jp (sadly not updated since 2008). I would work for a significant pay cut on such a project if someone's hiring. But also a tangent: anyone developing node-based software please give me sch…

> 100%. I want something that combines the multitrack timeline of ACID with the MIDI, control, and audio routing of a virtual modular synth or console.jp (sadly not updated since 2008). I would work for a significant pay cut on such a project if someone's hiring.

ardour.org has money in the bank right now. Make a proposal!

Re: Meadowlark, a DAW written in Rust

#88
post #52

Earlier quoted context omitted.

> Reaper desperately needs a Free Software competitor But why? And why "desperately"? Yes Reaper isn't free (neither beer nor freedom) but it is cheap and extremely customizable, extensible, scriptable, and it works well on Linux (even on a Pi). It also has many non-free competitors and isn't dominant in its space in any sense of the word.

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

Reaper is not the most powerful tool. There are dozens of things you can easily do in Ardour that you cannot do in Reaper, and just as many for which the opposite is true. Reaper has no clip launching model / session view, which is what allowed Live to change the entire zeitgeist of computer-based music production (now copied into Bitwig, Logic, DP and right about now, Ardour). It doesn't even get into the modulation ballpark that Bitwig is playing in, and completely lacks the freeform flow that FL Studio allows.

The reality remains that there is no "best" DAW for anyone. Plenty of people think that Ardour sucks, and for their workflow, you just have to respect their verdict. Just as many people try Reaper and find it impossible to use. Fortunately these days there's a DAW for everyone, and Meadowlark will only make that more true.

Re: Meadowlark, a DAW written in Rust

#89

Who, developers aside, gives a single whit what language it's written in? Just give us something useful, expandable, and with ongoing support for when bugs do appear. So much digital ink (and the associated mindshare) wasted in the design doc whinging on about how much Rust is better than C++ that they hardly talk about the DAW itself. And for features, immediately canning MP3, 4/4 time signatures, and sidechain rout…

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+ Quartz, gtk+, gtkmm, gtk-osx-docbook , harfbuzz, intltool, itstool, jpegsrcva, libarchive, libffi, libiconv, liblo, libogg, libpng, libsamplerate, libsigc++, libsndfile, libtool, libusb, libvorbis, libwebsockets, libxml, libxslt, lilv, LRDF, lv, libgnurx , NSS, NSS-PEM, pango, pangomm, pcre, pixman, portaudio svn rev, raptor, rasqal, rdflib, readline , readline , redland, rubberband, serd, sord, sratom, suil, taglib, tar, termcap, tiff, util-linux , uuid , vamp-plugin-sdk, xz, zlib

Re: Meadowlark, a DAW written in Rust

#90
post #73

Earlier quoted context omitted.

How is this a "closer" analogy? I motivated mine. The car without a parking sensor still gets you anywhere you want to go. This one only drives in straight lines, it's incapable of changing direction. There is a difference between "has a use case" and "fully-featured DAW". A wheelbarrow has use cases. It's not a car (and not a fully-featured one, at that). The decision to support non-12 tone equal temperament from th…

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/4 support is just like having no parking sensor.

You don't have an understanding of which features are important if you are not a user. (Speaking of which, I hope you at least drove a car!).

>I also don't have a horse in this race

Well, you commented on the issue. There's your horse.

>I just find it curious that you seem to be so extremely passionate

As a musician, yes, I'm so extremely passionate about the art and craft of music making - and the tools involved.

Just like literally any other musician. We are passionate because music is how we express passion.

On top of it, I get sad when people express unsubstantiated opinions when confidence on the issues that I care about.

>Why does it matter so much that it doesn't align with what you find the most important aspect of an MVP?

Why does it matter to the developers to say that this is a project "by musicians, for musicians"?

For the same reason, it matters to me, as a musician, to note that their MVP is not heading in the direction of their claim.

If anything, I'm helping that project by consulting them on the product / giving user feedback on the design.

Because I care, and I don't want to see a development effort wasted on something that people won't use because the developers did not understand the needs of the people they are writing this program for.

>I hope you've enjoyed working on your songs, just like the authors of Meadowlark are enjoying working on this DAW.

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

It makes sense, therefore, for musicians to comment on the discrepancy of something aiming to be a "fully featured DAW" without having the most basic feature (but shooting for advanced stuff few people need).

Post reply on HN