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 th…
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.
Meadowlark, a DAW written in Rust
71–80 of 124 posts
Re: Meadowlark, a DAW written in Rust
#72Who, 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 rout…
Re: Meadowlark, a DAW written in Rust
#73Earlier quoted context omitted.
"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)"
"Including a rear parking sensor is a non-goal for the MVP of the car we're building" seems to be a closer analogy. If you cannot use the MVP of the software for your use cases, that doesn't mean it cannot be worthwhile for anyone else.
The car without a parking sensor still gets you anywhere you want to go.
This one only drives in straight lines, it's incapable of changing direction.
There is a difference between "has a use case" and "fully-featured DAW". A wheelbarrow has use cases. It's not a car (and not a fully-featured one, at that).
The decision to support non-12 tone equal temperament from the get-go, but not something a simple as a goddamned waltz (or 6/8 beat, think Addams Family theme, or House Of The Rising Sun, or...) is perplexing. Tells me the DAW makers don't have their priorities straight.
May I ask you about what experience with audio production you have that you base your opinion/analogies on? I've been producing music[1] for about 15 years, and used DAWs from Cakewalk 6 to Cubase to Ableton. My opinions are based on this experience.
Re: Meadowlark, a DAW written in Rust
#74The 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 var…
100%. I want something that combines the multitrack timeline of ACID with the MIDI, control, and audio routing of a virtual modular synth or console.jp (sadly not updated since 2008). I would work for a significant pay cut on such a project if someone's hiring.
But also a tangent: anyone developing node-based software please give me schematic-style straight lines and angles to route connections! Noodles that look like real cables definitely take the skeuomorphism to 11, and plain straight lines without routing are really easy to implement, but they're both very impractical for more than just a few connections. I'll open source my old startup's Qt implementation of a node canvas if it helps.
Re: Meadowlark, a DAW written in Rust
#75I 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.
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.
Re: Meadowlark, a DAW written in Rust
#76* 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!
Re: Meadowlark, a DAW written in Rust
#77Earlier quoted context omitted.
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 e…
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.
Re: Meadowlark, a DAW written in Rust
#78The 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 var…
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
Re: Meadowlark, a DAW written in Rust
#79from 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 th…
>Do love first class support for non 12-TET! Disappointing that it assumes octaves though. There are important scales without them, e.g: https://en.wikipedia.org/wiki/Bohlen%E2%80%93Pierce_scale https://en.wikipedia.org/wiki/Gamma_scale
I suppose a solution here could to just ignore the octave part by having only a "single" octave.
Re: Meadowlark, a DAW written in Rust
#80Earlier quoted context omitted.
There might be language games at work here. '4/4 only' could be totally reasonable for an MVP from the perspective of the software developers, but not minimally viable from the perspective of a musician. Edit: Sorry, meant this as a reply to GP
Unfortunately, naive assumptions tend to bite later when the amount of rework needed to remove them is discovered. Being able to change time signatures is the sort of feature that is more important than delivering an anemic DAW sooner, and not only in theory as a "nice to have" but as proof of being able to be better than the competition.