Live data from Hacker News

Meadowlark, a DAW written in Rust

github.com

111–120 of 124 posts

Re: Meadowlark, a DAW written in Rust

#111

Earlier quoted context omitted.

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

Nice. I have not heard of rubberband. I'll definitely take a look into it! For FFT I believe there is a native fft crate in rust which we'll likely use. I just haven't gotten around to making any spectrometers yet.

We're not using any OSC in the mvp, but I'll keep those libraries in mind.

Someone else is independently working on their own LV2 and VST hosting crate, which is what we'll use too. We may need to end up implementing our own VST3 and AU hosting code when the time comes.

The goal of the rusty-daw-io crate is pretty much what you described in creating an abstraction over Jack, Pulseaudio, CoreAudio, and Alsa. Although I'm going to see if using bindings to RTAudio could save us time and effort here.

Also, what do you use offline audio analysis for? Sounds interesting.

Re: Meadowlark, a DAW written in Rust

#112

Earlier quoted context omitted.

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

Nice. I have not heard of rubberband. I'll definitely take a look into it! For FFT I believe there is a native fft crate in rust which we'll likely use. I just haven't gotten around to making any spectrometers yet. We're not using any OSC in the mvp, but I'll keep those libraries in mind. Someone else is independently working on their own LV2 and VST hosting crate, which is what we'll use too. We may need to end up i…

The offline analysis is for now used only for transient detection (so you can split by transient, and potentially "conform" a transient-laden track (e.g. percussion) to fit the tempo).

I wanted to use VAMP for tempo detection as part of the new clip launching features, but found that the code it uses really doesn't work well on short (1/2/4 bar loops). I ended up (for now) using Minibpm, a single-file implementation from Chris Cannam, who is responsible for both rubberband and VAMP. It's not perfect. but for the most part it works really well. Even the Live manual notes that they will sometimes "guess" the tempo incorrectly, typically by a factor of 2 in either direction.

Re: Meadowlark, a DAW written in Rust

#113

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…

Thanks a lot for your reply. I admit I didn't check the details of the mentioned situation and, as you said, it was a long time ago, nor was my wording correct. Great to hear the financial situation is not dire.

I also admit I haven't been following Ardour progress for some time, so my judgement wasn't fully informed. By "powerful" I meant not getting in the way and providing the wide set of tools. I mostly do mixing and editing, and I stand by my words that Reaper provides the most flexible and advanced workflow compared to Pro Tools, Logic and Studio One specifically, if you take the possibilities of 3d party enhancements of scripting/plugins. This doesn't mean it's the "best" DAW, as one doesn't necessarily want that, but for me it beats the mentioned competition hands down.

It's definitely time for me to try Ardour again, though!

Re: Meadowlark, a DAW written in Rust

#114

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…

Thanks a lot for your reply. I admit I didn't check the details of the mentioned situation and, as you said, it was a long time ago, nor was my wording correct. Great to hear the financial situation is not dire. I also admit I haven't been following Ardour progress for some time, so my judgement wasn't fully informed. By "powerful" I meant not getting in the way and providing the wide set of tools. I mostly do mixing…

The problem with talking about DAWs and workflows is that there are so many distinct workflows that it becomes almost meaningless.

Watch a discussion between e.g. an Ardour user and a Reaper user about how to do something, and it will often seem like they are in different worlds. "Well, I would never even begin to do it that way" will almost certainly come up.It would be even worse if you listen to, say, a Logic user and an FL Studio user. So many "basic concepts" that one of them uses every day, but that don't even appear on the other user's radar.

That means that a given "most flexible and advanced workflow" that matters a lot one user will probably be awkward for another, but it won't matter to most people, because they do it a different way.

Like I said, I'm glad for DAW users that there are so many choices, and I'm fairly sure that for the vast majority of people, there's one out there that will make them happy. What it is matters much less.

Re: Meadowlark, a DAW written in Rust

#115
post #71
post #50

Earlier quoted context omitted.

This is quite weird and unfortunate. Also, does the world need yet another DAW? There are dozens of DAWs, some free, some not. Most of them are excellent; all of them let you use non-4/4 time signatures.

Audacity replacement?

Audacity (as it currently stands) is an audio file editor, not a DAW. Under its new management, it seems likely that it will evolve into something with many DAW features within a year or two.

Re: Meadowlark, a DAW written in Rust

#116
post #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

I wish you good luck! This is a very ambitious project.

Just one word of advice based on my own experience: open source projects for creatives are a peculiar niche. Success isn't really based on technical merit or usability. The project with the best marketing often takes it all and leaves barely any breathing room for competing projects.

Re: Meadowlark, a DAW written in Rust

#117
post #90

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…

I'm also a music producer/sound designer and audio engineer.

Not being able to change the time signature isn't that big of a deal... Well over 90% of music is 4/4 and even other common ones like 3/4 can still be written in a DAW set to 4/4.

As a musician, I'd rather see them spend time working on some unique features rather than something niche that can be added on later (apparently somewhat trivially).

Seems like a whole lot of puff over nothing.

Re: Meadowlark, a DAW written in Rust

#118

Earlier quoted context omitted.

Nice. I have not heard of rubberband. I'll definitely take a look into it! For FFT I believe there is a native fft crate in rust which we'll likely use. I just haven't gotten around to making any spectrometers yet. We're not using any OSC in the mvp, but I'll keep those libraries in mind. Someone else is independently working on their own LV2 and VST hosting crate, which is what we'll use too. We may need to end up i…

The offline analysis is for now used only for transient detection (so you can split by transient, and potentially "conform" a transient-laden track (e.g. percussion) to fit the tempo). I wanted to use VAMP for tempo detection as part of the new clip launching features, but found that the code it uses really doesn't work well on short (1/2/4 bar loops). I ended up (for now) using Minibpm, a single-file implementation…

Neat!

Re: Meadowlark, a DAW written in Rust

#119
post #85

Earlier quoted context omitted.

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

I wish you good luck! This is a very ambitious project. Just one word of advice based on my own experience: open source projects for creatives are a peculiar niche. Success isn't really based on technical merit or usability. The project with the best marketing often takes it all and leaves barely any breathing room for competing projects.

Noted!

I am planning on having a flashy website and also YouTube videos showing it off (once it's ready of course). A lot of focus is being put into the UI and making it pretty, which I believe is important in making first impressions.

Other than that I don't currently have plans for marketing. But I definitely am open to working with people who have more marketing prowess.

Re: Meadowlark, a DAW written in Rust

#120
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…

I'm also a music producer/sound designer and audio engineer. Not being able to change the time signature isn't that big of a deal... Well over 90% of music is 4/4 and even other common ones like 3/4 can still be written in a DAW set to 4/4. As a musician, I'd rather see them spend time working on some unique features rather than something niche that can be added on later (apparently somewhat trivially). Seems like a…

I once wrote a track where 4/4 changed into 3/4 mid-song, and then back in a beta DAW that didn't have a time signature track at the time (Energy XT2).

So while it's possible, it's also annoying. You can't use the DAW click, and clips don't align with (what the DAW thiks are) measures.

This is added friction, and you know what it did? It made me stay away from making music like that because I don't want to be clicking around the DAW when I'm making music, I want things to work.

Making the 10% use case annoying while prioritizing the 0.0001% use case (how much of music made today is microtonal?) does not result in a general purpose DAW.

>apparently somewhat trivially

As a software engineer, I can assure you that there is no such thing. The cost of changing something we a bottom level (and the grid in a DAW is such an object) is always high.

If it's trivial to add later, it's less than trivial to add now. If it's difficult to add now, then the project is dead in the water because 4/4 is, for all intents and purposes, hard-wired.

Either way, it's concerning either from product or engineering perspective.

Post reply on HN