-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
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...
Alright, the main developer of Meadowlark here. Let me answer some concerns I see in the comments.
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!
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) for a general chat.
"- 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 great 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.