BillyDM

The writer of the blogpost here.

The popularity of this post has really caught me at an awkward time. I want to clarify some things: https://billydm.github.io/blog/clarifying-some-things/

Alright, I get it. Non-4/4 time signatures are in much higher demand than I originally thought.

* edit - I'm not trying to sound mean. I just want to make it clear for those who may have not read my other comments on this HN post.

I thought it was clear that these non-features are only for the MVP, not the released "1.0 version", but apparently I was wrong. The "final" 1.0 version will indeed have support for other time signatures. Although because demand is apparently very high, I will likely add it to the MVP as well.

The way I have this designed, it is in fact trivial to add other time signatures later. The backend code only uses musical time as a unit of beats, it does not care about measures. Measures are purely just a visual thing for the GUI. Yes there are special plugins that care about measure like drum sequencers and advanced arpeggiators, but neither of those things are planned for MVP, so it's not like we will have to "rewrite" them.

What is not trivial to rewrite is support for non-western scales and microtonal stuff, which is why those are being included in the MVP.

The title of this HN post was updated, it now has correctly removed "fully-featured" in the title. Neither I or anyone on the Meadowlark team made this HN post. We got publicity a lot sooner than we thought we would, so we weren't even fully ready to make a full public announcement on the project yet. The design doc is still somewhat of a draft.

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.

Neat!

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.

Thinking about it some more, it might be more accurate to call it a "proof of concept" rather than MVP.

Oooh, that clip launching stuff looks nifty! I'll have to try it out.

I'll also take a look at temporal. You definitely have a point when it comes to avoiding mistakes of the past. Your help and guidance is appreciated!

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 may end up creating our own solution under the rusty-daw-io repo, although someone is also looking into creating bindings to RTAudio.

We are using femtovg in place of cairo. The developer of our GUI library is also working on improving the text layout and shaping inside femtovg.

We are using Symphonia for decoding audio files (although we may end up binding to ffmpeg if it doesn't work out).

We aren't using any networking in mvp, but there is no shortage of networking crates in rust.

We will also likely use bindings to libsamplerate if we find that a native Rust one is not good enough.

I don't recognize a lot of those dependencies. If there is a crucial one I missed, please let me know!

Of course some would point out why use Rust if you are using so many non-Rust dependencies? That is a fair argument. Me and my team just really prefer writing in Rust, so we are willing to put in the extra effort of using bindings.

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

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

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.

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.

"- Are there any plans to have some user-facing API for plugins/scripting? Professional workflows vary widely and automation helps a lot."

Yes, a scripting API is planned. The GUI is being designed from the ground-up to where every action will go through an event system, so script will be able to do pretty much anything the GUI can do.

A lot of the backend components will also be separated into a separate repo under the RustyDAW project, allowing someone else to create their own DAW with their own GUI if they wish.

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

We're not too sure on this one yet, it mostly depends on how many features the GUI library we are using will get. We hope to have a GUI that is as flexible as possible.

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

We are currently working on a complex audio graph in the https://github.com/RustyDAW/rusty-daw-audio-graph repo. This will hopefully allow us to support any kind of complex audio graph structure.

So far this audio graph only supports mono and stereo audio, but we can easily add more ports for multichannel audio in the future.

Beyond MVP we will likely add either a Live/Bitwig style horizontal rack, or a FL Studio Patcher style plugin for advance routing. It's still being decided on which one we will go with.

* edit - fix typo

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` 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!