3 ms·

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 ma

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

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