13 ms·

Meadowlark, a DAW written in Rust

153 points by ushakov 5y ago

BillyDM 5y ago
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. When I mentioned fully-featured, I meant it in regard to the end goal of my vision, so people would get a better idea on what the project is heading for and why I made some of the design decisions. I thought there wouldn't be any confusion on that, but apparently I was wrong. Third, my plan in regard to time signature is to abstract away all the logic into the `https://github.com/RustyDAW/rusty-daw-timeline 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. This will allow us to add time signature changes as well as automation of tempo changes in the future. I figured 4/4 time was good enough for a proof-of-concept MVP. Apparently there is a lot of demand for other time signatures, so I could add it higher in the priority list either after MVP or in the MVP if we have the time. Fourth, my decision of Rust was mostly decided because of the great Rust community. I've found many friends on the Rust Audio Discord server, and I would never have started this project without them. Plus I also believe that the better memory safety and modularity of Rust will make it much easier to maintain a larger project with less time spent debugging and fixing crashes. Fifth, it's a dream of mine have a whole FLOSS ecosystem of creative apps that any artist around the world can use without restriction. Apps like Blender, Gimp, Krita, Inkscape, etc. However, I personally find the current state of FLOSS DAWs to be lacking, especially when it comes to MIDI editing, automation, and sound design. Ardour is okay, but only if you don't mess with MIDI. Nothing I've seen yet comes close to the usability of commercial DAWs, and I wish to change that. (With maybe the exception of ZRythm, but it is just too unstable to use imo, and it's also not truly FLOSS as it requires a paid license to download the binaries, (same for Ardour on non-Linux systems)). Finally, not much development has been done on the GUI side yet since I'm still waiting on the GUI library to stabilize and add the features I need. Hopefully I can have more to actually show fairly soon!
- PaulDavisThe1st 5y ago
  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 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 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!
  - BillyDM 5y ago
    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).
lowbloodsugar 5y ago
>"This project is still in the early stages of development. Please see below on how you can get involved." Title is wrong. This is not a fully-featured DAW. It intends to be.
beepbooptheory 5y ago
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 that going to happen? Its definitely more something used for more experimental-minded musicians I guess, but it has huge support and makes things like interfacing with cv pretty simple, along with a million other things that are otherwise so fussy with midi. Do love first class support for non 12-TET! Overall a huge, exciting effort, can't imagine how hard this is.
- shams93 5y ago
  Yeah time signature is more complex than you might think which is why a lot of hardware drum machines in the 80s could only do 4/4 or maybe 3/4 and 4/4 with their limited processesing.
- jb1991 5y ago
  That is an odd "non-goal" indeed, and also unfortunate; it's like making a painting app but not giving users access to basic colors.
  - techbio 5y ago
    Or fixing headline widths to 60 characters plus "..."
  - royjacobs 5y ago
    The document states this is a non-goal for the MVP, not a non-goal for the final product.
    - romwell 5y ago
      "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)"
mpfundstein 5y ago
"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)
- deleted 5y ago
  [deleted]
- tialaramex 5y ago
  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 examples to calibrate, the first one is real, the second for reasons that will become obvious is hypothetical: 1. My friend Chris wanted to do a trivial thing in Gimp, but like, a lot of times. So, he finds out how to write scripts that run inside Gimp, he writes a script, it works immediately - problem solved, might as well mail it off in case anybody else finds it useful. Last time I looked, his script is out-of-the-box in Gimp. 2. Back in 2016 if you wrote a small non-bug-fix change for Apache OpenOffice, you needed to build the full C++ application. Then you could send patches over to their dev team. If you'd done this, those patches still aren't in a shipping product, the next non-bug-fix release AOO 4.2 was at the time scheduled for "soon" hopefully 2017. Last time I looked they were lamenting that "We have missed our goal on going into the beta in 2019" but still hadn't shipped anything.
  - SOLAR_FIELDS 5y ago
    Regarding #2, everyone has essentially moved over to LibreOffice several years ago, thanks to Oracle's shenanigans. I think Oracle eventually walked back whatever it was doing that made everyone fork and switch over, but by then it was too late. It seems like the only reason OpenOffice has continued its zombie-like path forward over the past few years is because of name recognition.
ZoomZoomZoom 5y ago
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 vary widely and automation helps a lot. - How flexible the UI is going to be? Multi-monitor setups of different configurations are very frequent in studios, free docks and/or floating windows are very important. - I see you mention sidechain routing, but it's unclear what are the plans on multichannel audio and, more importantly, the routing possibilities. I'd love to see some kind of node editor for this where you can visualize and manage complex routing schemes for your projects just dragging nodes and noodles.
- bambax 5y ago
  > 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.
  - ZoomZoomZoom 5y ago
    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 close. I suppose, Harrison income is minuscule. Thank god the development didn't cease some years ago when Davis wanted to step down, that would be a loss.
    - PaulDavisThe1st 5y ago
      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.
gmueckl 5y ago
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?
- fxtentacle 5y ago
  It's in the GitHub description, too: "An open-source and fully-featured Digital Audio Workstation, made by musicians, for musicians" Apparently, the authors drank their own cool-aid.
- tekstar 5y ago
  In defence of the project, it doesn't look like the Github authors posted it to HN.
- rectang 5y ago
  It's aspirational, jeez. Their eventual goal is to be a "fully featured DAW" as opposed to some other kind of tool. At least that's how I interpret it.
  - gmueckl 5y ago
    Aspirations are fine, but you need to separate aspirations from the status quo in your communications. The HN headline fails in that regard.
    - sodality2 5y ago
      It doesn't seem like the person who posted it is the repo owner/maintainer...
  - emerged 5y ago
    So is me landing on Mars, but the buzz killers always call me out for announcing that I’m a fully featured Mars astronaut.
- 5y ago
falcolas 5y ago
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 routing makes this little more than a toy when compared to existing offerings. I'll watch this to see what this becomes, but I don't have high hopes, not with the current stated direction.
- drogus 5y ago
  This site is for developers, isn't it? For me this is interesting, cause I could see myself contributing to a Rust project, I'm guessing there's more people who think that way.
  - falcolas 5y ago
    This website is for developers; the product feature page should be about the product, not the programmers.
    - berkes 5y ago
      Do you consider the README on Github a "product feature page"?
      - falcolas 5y ago
        No, but I do consider a "Design Document" to be a product feature page. It's full of product features (and non-features) after all (when it's not going on about Rust). https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DESIGN_DOC.md https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DESIGN...
  - lijogdfljk 5y ago
    Agreed. Furthermore, Rust is/was imo a controversial language - early on some argued it was "too difficult" to write "real" applications in it. I'm super interested in real world performance intensive applications written in Rust, Haskell, etc. Language matters to me, even if i don't plan on participating.
ehutch79 5y ago
I feel like a lot of the 'non goals' are things that come from fundamental design qualities. plan for time signatures and tempo changes, make rendering audio pluggable from the start. I feel like they're just going to be ripping out a lot of subsystems later due to poor planning
ZoomZoomZoom 5y ago
It's also a bit disappointing to see another project chooses proprietary service for the communication. I joined #rust-audio:matrix.org almost a year ago and just figured the project was dead since the room isn't bridged and it's completely quiet there. Turns out everyone's on Discord. If you're a musician, sound industry professional or just a hobbyist, I invite you to join the Mixing room on the Matrix.org server (https://matrix.to/#/#mixing:matrix.org https://matrix.to/#/#mixing:matrix.org) for a general chat.
- jcelerier 5y ago
  Yeah, I used to be active in various audio & development-related Discord instances and one day my account got banned with no good reason and no possibility for appeal. Fuck that.
- deleted 5y ago
  [deleted]
mejutoco 5y ago
The design mockups have a similar vibe to Bitwig.the color scheme and general ui (https://www.bitwig.com/ https://www.bitwig.com/). I say that as a good thing, I really like Bitwig.
- bambax 5y ago
  They also mention Bitwig several times in the design document (and no other DAW), so it's probably their main source of inspiration.
rvz 5y ago
> Proudly written in Rust™ Great but 'Does It Actually Work?®' If it is to be taken seriously, it has to work with the existing plugins and software that is out there and must work better than the similar alternatives as well. If not, then no thanks and no deal.
StarBrilliant 5y ago
I don’t understand the definition of “fully-featured”. Can a software be called “fully-featured” before the development is even far from complete? Oh, obviously “fully-featured” doesn’t include time signature support.
- kennywinker 5y ago
  I understood fully-featured to mean "intended to have a broad feature set". There's no list of features that every DAW must have - so if you're going to be this literal I could easily argue that any DAW is not "fully-featured" because it's missing some feature that another DAW has.
  - ehutch79 5y ago
    Yeah, but this one is missing ALL the features.

153 points by ushakov 5y ago

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. When I mentioned fully-featured, I meant it in regard to the end goal of my vision, so people would get a better idea on what the project is heading for and why I made some of the design decisions. I thought there wouldn't be any confusion on that, but apparently I was wrong. Third, my plan in regard to time signature is to abstract away all the logic into the `https://github.com/RustyDAW/rusty-daw-timeline 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. This will allow us to add time signature changes as well as automation of tempo changes in the future. I figured 4/4 time was good enough for a proof-of-concept MVP. Apparently there is a lot of demand for other time signatures, so I could add it higher in the priority list either after MVP or in the MVP if we have the time. Fourth, my decision of Rust was mostly decided because of the great Rust community. I've found many friends on the Rust Audio Discord server, and I would never have started this project without them. Plus I also believe that the better memory safety and modularity of Rust will make it much easier to maintain a larger project with less time spent debugging and fixing crashes. Fifth, it's a dream of mine have a whole FLOSS ecosystem of creative apps that any artist around the world can use without restriction. Apps like Blender, Gimp, Krita, Inkscape, etc. However, I personally find the current state of FLOSS DAWs to be lacking, especially when it comes to MIDI editing, automation, and sound design. Ardour is okay, but only if you don't mess with MIDI. Nothing I've seen yet comes close to the usability of commercial DAWs, and I wish to change that. (With maybe the exception of ZRythm, but it is just too unstable to use imo, and it's also not truly FLOSS as it requires a paid license to download the binaries, (same for Ardour on non-Linux systems)). Finally, not much development has been done on the GUI side yet since I'm still waiting on the GUI library to stabilize and add the features I need. Hopefully I can have more to actually show fairly soon!

PaulDavisThe1st 5y ago
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 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 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!
- BillyDM 5y ago
  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).

lowbloodsugar 5y ago

>"This project is still in the early stages of development. Please see below on how you can get involved." Title is wrong. This is not a fully-featured DAW. It intends to be.

beepbooptheory 5y ago

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 that going to happen? Its definitely more something used for more experimental-minded musicians I guess, but it has huge support and makes things like interfacing with cv pretty simple, along with a million other things that are otherwise so fussy with midi. Do love first class support for non 12-TET! Overall a huge, exciting effort, can't imagine how hard this is.

shams93 5y ago
Yeah time signature is more complex than you might think which is why a lot of hardware drum machines in the 80s could only do 4/4 or maybe 3/4 and 4/4 with their limited processesing.
jb1991 5y ago
That is an odd "non-goal" indeed, and also unfortunate; it's like making a painting app but not giving users access to basic colors.
- techbio 5y ago
  Or fixing headline widths to 60 characters plus "..."
- royjacobs 5y ago
  The document states this is a non-goal for the MVP, not a non-goal for the final product.
  - romwell 5y ago
    "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)"

mpfundstein 5y ago

"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)

deleted 5y ago
[deleted]
tialaramex 5y ago
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 examples to calibrate, the first one is real, the second for reasons that will become obvious is hypothetical: 1. My friend Chris wanted to do a trivial thing in Gimp, but like, a lot of times. So, he finds out how to write scripts that run inside Gimp, he writes a script, it works immediately - problem solved, might as well mail it off in case anybody else finds it useful. Last time I looked, his script is out-of-the-box in Gimp. 2. Back in 2016 if you wrote a small non-bug-fix change for Apache OpenOffice, you needed to build the full C++ application. Then you could send patches over to their dev team. If you'd done this, those patches still aren't in a shipping product, the next non-bug-fix release AOO 4.2 was at the time scheduled for "soon" hopefully 2017. Last time I looked they were lamenting that "We have missed our goal on going into the beta in 2019" but still hadn't shipped anything.
- SOLAR_FIELDS 5y ago
  Regarding #2, everyone has essentially moved over to LibreOffice several years ago, thanks to Oracle's shenanigans. I think Oracle eventually walked back whatever it was doing that made everyone fork and switch over, but by then it was too late. It seems like the only reason OpenOffice has continued its zombie-like path forward over the past few years is because of name recognition.

ZoomZoomZoom 5y ago

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 vary widely and automation helps a lot. - How flexible the UI is going to be? Multi-monitor setups of different configurations are very frequent in studios, free docks and/or floating windows are very important. - I see you mention sidechain routing, but it's unclear what are the plans on multichannel audio and, more importantly, the routing possibilities. I'd love to see some kind of node editor for this where you can visualize and manage complex routing schemes for your projects just dragging nodes and noodles.

bambax 5y ago
> 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.
- ZoomZoomZoom 5y ago
  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 close. I suppose, Harrison income is minuscule. Thank god the development didn't cease some years ago when Davis wanted to step down, that would be a loss.
  - PaulDavisThe1st 5y ago
    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.

gmueckl 5y ago

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?

fxtentacle 5y ago
It's in the GitHub description, too: "An open-source and fully-featured Digital Audio Workstation, made by musicians, for musicians" Apparently, the authors drank their own cool-aid.
tekstar 5y ago
In defence of the project, it doesn't look like the Github authors posted it to HN.
rectang 5y ago
It's aspirational, jeez. Their eventual goal is to be a "fully featured DAW" as opposed to some other kind of tool. At least that's how I interpret it.
- gmueckl 5y ago
  Aspirations are fine, but you need to separate aspirations from the status quo in your communications. The HN headline fails in that regard.
  - sodality2 5y ago
    It doesn't seem like the person who posted it is the repo owner/maintainer...
- emerged 5y ago
  So is me landing on Mars, but the buzz killers always call me out for announcing that I’m a fully featured Mars astronaut.
5y ago

falcolas 5y ago

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 routing makes this little more than a toy when compared to existing offerings. I'll watch this to see what this becomes, but I don't have high hopes, not with the current stated direction.

drogus 5y ago
This site is for developers, isn't it? For me this is interesting, cause I could see myself contributing to a Rust project, I'm guessing there's more people who think that way.
- falcolas 5y ago
  This website is for developers; the product feature page should be about the product, not the programmers.
  - berkes 5y ago
    Do you consider the README on Github a "product feature page"?
    - falcolas 5y ago
      No, but I do consider a "Design Document" to be a product feature page. It's full of product features (and non-features) after all (when it's not going on about Rust). https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DESIGN_DOC.md https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DESIGN...
- lijogdfljk 5y ago
  Agreed. Furthermore, Rust is/was imo a controversial language - early on some argued it was "too difficult" to write "real" applications in it. I'm super interested in real world performance intensive applications written in Rust, Haskell, etc. Language matters to me, even if i don't plan on participating.

ehutch79 5y ago

I feel like a lot of the 'non goals' are things that come from fundamental design qualities. plan for time signatures and tempo changes, make rendering audio pluggable from the start. I feel like they're just going to be ripping out a lot of subsystems later due to poor planning

ZoomZoomZoom 5y ago

It's also a bit disappointing to see another project chooses proprietary service for the communication. I joined #rust-audio:matrix.org almost a year ago and just figured the project was dead since the room isn't bridged and it's completely quiet there. Turns out everyone's on Discord. If you're a musician, sound industry professional or just a hobbyist, I invite you to join the Mixing room on the Matrix.org server (https://matrix.to/#/#mixing:matrix.org https://matrix.to/#/#mixing:matrix.org) for a general chat.

jcelerier 5y ago
Yeah, I used to be active in various audio & development-related Discord instances and one day my account got banned with no good reason and no possibility for appeal. Fuck that.
deleted 5y ago
[deleted]

mejutoco 5y ago

The design mockups have a similar vibe to Bitwig.the color scheme and general ui (https://www.bitwig.com/ https://www.bitwig.com/). I say that as a good thing, I really like Bitwig.

bambax 5y ago
They also mention Bitwig several times in the design document (and no other DAW), so it's probably their main source of inspiration.

rvz 5y ago

> Proudly written in Rust™ Great but 'Does It Actually Work?®' If it is to be taken seriously, it has to work with the existing plugins and software that is out there and must work better than the similar alternatives as well. If not, then no thanks and no deal.

StarBrilliant 5y ago

I don’t understand the definition of “fully-featured”. Can a software be called “fully-featured” before the development is even far from complete? Oh, obviously “fully-featured” doesn’t include time signature support.

kennywinker 5y ago
I understood fully-featured to mean "intended to have a broad feature set". There's no list of features that every DAW must have - so if you're going to be this literal I could easily argue that any DAW is not "fully-featured" because it's missing some feature that another DAW has.
- ehutch79 5y ago
  Yeah, but this one is missing ALL the features.