...
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.
As the author of an open source DAW that already supports non-4/4 time ...
first of all, there are some annoying details to even get as far as the full scope of western metric notation. For example, compound time: 6/8 does not mean "6 eighth notes per bar", even though there's a growing body of DAW-trained young people who seem to think that it does.
But "worse" (harder, is perhaps a better phrase), dealing non-western concepts of meter requires moving beyond "just divide it however is needed". A relatively simple case would be music from the Balkan/Byzantine cultures, which are much better represented using a notation form like [ 3L + 2S + 3L ] ("3 long beats, 2 short beats, 3 long beats"). There is a great deal of music from around the world that uses this structure, and even if a western notation like 8/N migh theoretically capture this, it doesn't contain the information required to play it.
Moving to even harder metrical forms, Carnatic and Hindustani talas are always conceived on in their own cultures as rhythmic cycles that cannot be decomposed to simple western notation. Even teental, perhaps the most widespread and maybe the simplest, is not usefully representable using western time signatures (it consists of a cycle of 16 beats, where the timbre of the beats creates rhythmic motion and structure).
FWIW, I hope to add the [ N + M + P ] form to Ardour in the not (too) distant future.
"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.
No, being able to use different time signatures is essential in music. Time signatures are a basic building block required to define the vast majority of musical styles in the world. All of the western classical and popular music builds its rhythms and structure on a whole collection of time signatures (4/4, 3/4, 6/8, 2/4 are the more common ones). 4/4 is the most common time signature, but at least half of the music that follows any kind of time signature uses different ones. Also, a quite significant number of pieces use changes in time signatures throughout the piece to great effect.
To come back to your analogy, a feature that is akin to a rear parking sensor in a car would be something like retroactive recording.
If by "different things" you mean "a functioning daw at all".
4/4 is not the only time signature... 3/4, 6/8 are really common too. Not to mention 5/4, 7/4, and others. Not supporting other time signatures is like building a car with wheels but without a steering wheel, and then handwaving criticism as "wanting different features".
As a musician/composer it's beyond absurd to have only 4/4 as the option- it's a non-starter. As a software engineer this seems like a fundamental code issue, because it really should be dynamically handled, and time signature is important for other components.
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.
I'm not sure why the amount of audio production experience is relevant in this case. I also don't have a horse in this race. I just find it curious that you seem to be so extremely passionate about taking a random item in a _design_ for an _MVP_ and drawing all sorts of conclusions about both the tool and the authors of this tool. Why does it matter so much that it doesn't align with what you find the most important aspect of an MVP?
Again, this is even just a _design_ for an MVP. If it doesn't align with what _you_ find important then that's fine. Just use something else, you've clearly been doing so for about 15 years. I hope you've enjoyed working on your songs, just like the authors of Meadowlark are enjoying working on this DAW.
TL;DR: you don't have experience in the subject you opine on, but wonder why someone who does would.
I'll address these points below.
---------
>I'm not sure why the amount of audio production experience is relevant in this case.
Because that's what would make you qualified to have an opinion on the matter, or make an analogy.
If you don't use a DAW regularly to make music, you are not qualified to say that lack of 3/4 support is just like having no parking sensor.
You don't have an understanding of which features are important if you are not a user. (Speaking of which, I hope you at least drove a car!).
>I also don't have a horse in this race
Well, you commented on the issue. There's your horse.
>I just find it curious that you seem to be so extremely passionate
As a musician, yes, I'm so extremely passionate about the art and craft of music making - and the tools involved.
Just like literally any other musician. We are passionate because music is how we express passion.
On top of it, I get sad when people express unsubstantiated opinions when confidence on the issues that I care about.
>Why does it matter so much that it doesn't align with what you find the most important aspect of an MVP?
Why does it matter to the developers to say that this is a project "by musicians, for musicians"?
For the same reason, it matters to me, as a musician, to note that their MVP is not heading in the direction of their claim.
If anything, I'm helping that project by consulting them on the product / giving user feedback on the design.
Because I care, and I don't want to see a development effort wasted on something that people won't use because the developers did not understand the needs of the people they are writing this program for.
>I hope you've enjoyed working on your songs, just like the authors of Meadowlark are enjoying working on this DAW.
Well I'm not posting my songs on HackerNews in a post saying "Background Music To Write Code To: By Programmers, For Programmers". That would be dishonest.
It makes sense, therefore, for musicians to comment on the discrepancy of something aiming to be a "fully featured DAW" without having the most basic feature (but shooting for advanced stuff few people need).
If you don't want to see development effort wasted I hope you'll contribute to the project. I'm sure the authors will applaud and enjoy your passion.
>Well I'm not posting my songs on HackerNews in a post saying "Background Music To Write Code To: By Programmers, For Programmers".
Neither were the authors of the DAW, someone else posted it using this title.
(btw I do have plenty of experience using DAWs (going back to Notator on the Atari ST) and have been an amateur musician since childhood. I just don't see how it's relevant in a discussion about an aspirational MVP design. Thanks for assuming the worst, though!)
I'm also a music producer/sound designer and audio engineer.
Not being able to change the time signature isn't that big of a deal... Well over 90% of music is 4/4 and even other common ones like 3/4 can still be written in a DAW set to 4/4.
As a musician, I'd rather see them spend time working on some unique features rather than something niche that can be added on later (apparently somewhat trivially).
I once wrote a track where 4/4 changed into 3/4 mid-song, and then back in a beta DAW that didn't have a time signature track at the time (Energy XT2).
So while it's possible, it's also annoying. You can't use the DAW click, and clips don't align with (what the DAW thiks are) measures.
This is added friction, and you know what it did? It made me stay away from making music like that because I don't want to be clicking around the DAW when I'm making music, I want things to work.
Making the 10% use case annoying while prioritizing the 0.0001% use case (how much of music made today is microtonal?) does not result in a general purpose DAW.
>apparently somewhat trivially
As a software engineer, I can assure you that there is no such thing. The cost of changing something we a bottom level (and the grid in a DAW is such an object) is always high.
If it's trivial to add later, it's less than trivial to add now. If it's difficult to add now, then the project is dead in the water because 4/4 is, for all intents and purposes, hard-wired.
Either way, it's concerning either from product or engineering perspective.
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.
Yes, as long as your use-case only includes driving straight forward, the MVP is fine. Supporting non-4/4 time is such a fundamental change that not being to turn is a good analogy.
The rule of thumb is that you need to design to support at least 3 different use cases from the start if you want to create something that can viably extend to being a generic product.
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.
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.
Yep. I don't remember the post, but in a (relatively) recent thread on DAWs, some developer was talking about how surprised they'd been by the complexity latent (pun acknowledge but not intended) in management of the timing grid.
Because you'd have Hours Of Fun with all the drums being triplets if you want to sequence them.
4/4 with triplets, swung rhythms, etc are not supported by their design.
And while you can record things, editing becomes clunky when the grid isn't there for you. At that point, it's easier to re-record the part. Or switch to another DAW.
Doesn't this non-goal dooms the project to be an edm/"bedroom-producer"-driven one? Maybe the goal isn't a general purpose DAW. But that would otherwise contract with the claim "fully-featured".
You seem to have found a significant weak spot: apart from the dubious approach of rejecting MIDI, ignoring OSC and reinventing the wheel, the assumption of octaves is very gratuitous and a net complication.
MIDI supports 127 different notes and it is the synthesizer's job to decide their pitch; likewise, a piano roll has a predefined set of notes, each with its own pitch.
It's therefore very unfortunate that they decide to be much less flexible than MIDI and represent notes as
> The octave of the note, stored as an i8. For example, in 12-TET, a value of 0 means the octave with root note C4, 1 is the octave with root note C5, -1 is the octave with root note C3, etc.
> The index of the note in the scale stored as a u16. For example, in 12-TET, a value of 0 means C, a value of 1 means C#, a value of 2 means D, etc.
clearly closing the door to flat identifier spaces like the MIDI note number and to more general representations of tuning with non-octave repeating intervals or with the pitch of every note.
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.
Not just somewhat arbitrarily invented scales from the west ... in Byzantine musical culture, they do not have or assume the concept of "octave equivalence". That is, doubling the frequency of a sound does not, in classical Byzantine music, constitute "the same note". Byzantine musical culture is wonderful in so many ways. They rarely notate pitches, preferring to notate intervals, which as anyone who has ever tranposed a song from one western major scale to another will understand, is far more of a deep representation of a melody than pitches.
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.
I know, my question still stands though, I get that its not a goal right now, just seems like something you should be thinking about from the beginning
So strange! Very much add odds with the "full-featured" label. No Mission: Impossible theme (5/4)? No Pink Floyd - Money (7/4)? No Seal - Kiss from a rose? No Hey Ya!? Metallica - One / Nothing Else Matters? Fallin'?
Edit: This was under "non-goals" for the MVP. Completely understandable...
Agree with your question. I'm in the planning stages of a music notation app for myself and supporting arbitrary time signatures seems (from the ignorant outside!) as foundational as supporting a single time signature.
Super ignorant on my part, but still. I suspected that the time signature was a calculation relative to the BPM. Once i have the difficulty for calculating how long a single beat is, and the significance of the beat, i would expect i could apply those primitives to any time signature. Which is to say once i write the function, don't i support all time signatures?
It is a superstructure. There are notes with the times of their events (MIDI note on, note off, polyphonic aftertouch, etc.) and editing operations that ultimately alter those times; calculating the modified times from beat divisions, with beats beginning according to a current BPM rate, is an abstraction that introduces arbitrary entities for the convenience of the composer.
Unless I'm completely mistaken, even a basic tool like quantization is dependent on the time signature. Time signatures crop up in all kinds of other things, too. More advanced arpeggiators, sequencers, delays etc. understand tempo and time signatures and MIDI timing works on this basis, too.
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.
I don't know. Probably none. But I'm quite confident no musician or other user of a DAW cares what language it's written in.
If the goal is to demonstrate that Rust can be used to write that kind of software, then hey why not; but they will need to have users at some point, to be able to actually call it a DAW.
Audacity (as it currently stands) is an audio file editor, not a DAW. Under its new management, it seems likely that it will evolve into something with many DAW features within a year or two.
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.
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.
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.
Rust is about as controversial as Python these days, though for different reasons.
To be clear, I'm not annoyed at it being called out here (much - it gets old no matter which langauge is pimped). I'm most annoyed at how much space in the features doc, which should be about the project, not the internals.
This is an early version of the project, so this is most likely not directed at end users. Why would you even address end users at this point? Nobody will use it for a long time anyway, so in my opinion is a great move to address potential contributors in the design doc.
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).
I think a lot of us who've used the open source linux tools for complex tasks have been bitten by weird UI problems and unstable code (Video editing comes to mind for me).
Its much better now, but having a really solid foundation and fewer crashes is a huge win. With the new components they want to build in Rust is kind of exiting. DAWs are a pretty large complex software and a good test for Rust as a language.
It will take not insignificant time to optimize and get the feature complete but optimistic this takes off and improves open source software.
It seemed to me they were justifying using a new language, because its a little crazy. A lot of existing components and things could be brought together that are open source and already in C++ (or C...).
Honestly as a end user, if it works and works well, you won't care (much like you use websites without worrying about the software stack that powers it). But if you want to contribute to building the software you might care.
I am a developer and I couldn't care less about what language $TOY is written in, or if it is open source or not.
In this case, though, what is really advertised is the project itself, not the product, which doesn't exist and likely to not exist for a while. In this context, the language choise is probably as relevant as the design goals.
There’s a comment like this on every post ending in “written in Rust.” The people who care about this include people who follow the development of the Rust ecosystem because it’s a sign of how capable the ecosystem is becoming.
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.
A large chunk of those libraries come the depstack of our GUI library (GTKmm). Pango, Harfbuzz etc. are all just dependencies for the GUI library, but also our own Canvas library (we had to write our own, since nothing out there came close to requirements; the Canvas is heavily Cairo-based but could fairly trivially be ported to any 2D drawing API).
More DSP-y/audio-centric libraries would include:
fftw - fastest fourier transform in the west
rubberband - the only open source stretcher worth using (though we do have code to use soundtouch also)
lilv,serd,sord,sratom,suil - LV2 infrastructure
vamp-plugin-sdk - for offline (non-realtime) audio analysis
aubio - used by VAMP
liblo - almost certainly the best FLOSS OSC library
We created our own audio/MIDI I/O abstraction initially based on JACK (which was initially based on Ardour :). The Windows version uses PortAudio which has its pros and cons; the macOS version directly uses CoreAudio; the Linux version directly uses ALSA (and then there is a separate cross-platform JACK one too).
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.
The offline analysis is for now used only for transient detection (so you can split by transient, and potentially "conform" a transient-laden track (e.g. percussion) to fit the tempo).
I wanted to use VAMP for tempo detection as part of the new clip launching features, but found that the code it uses really doesn't work well on short (1/2/4 bar loops). I ended up (for now) using Minibpm, a single-file implementation from Chris Cannam, who is responsible for both rubberband and VAMP. It's not perfect. but for the most part it works really well. Even the Live manual notes that they will sometimes "guess" the tempo incorrectly, typically by a factor of 2 in either direction.
I don't know, but it's hardly as interesting as whether someone can create a full cross-platform GUI using the ecosystem. Just a year ago the support for that was next-to-nonexistent.
My point is that for large-scale software like a DAW, you either need a LOT more than a cross-platform GUI, or you will be reimplementing a very very large body of code that has existed in FLOSS form (but other languages) for (in some cases) decades.
Or just generating bindings for it. Bindgen exists for this reason. A minority of libraries such as that will require a smarter wrapper but for most it is probably sufficient to just use it in a reasonable way.
You are missing something. For a piece of Rust software to run in any widely used computing environment, it is required to interface with a large body of non-Rust software via a non-typechecked ABI. Moreover, the Rust standard library itself contains many, many instances of the unsafe keyword. The benefits of Rust safety do not come from building a hermetically isolated tower of pure safe Rust code from the ground up, and those benefits do not become null and void the moment you include one C library used via FFI.
Rust safety is about being able to take an unsafe component, encapsulate its implementation details, and encode sound usage patterns for that component in a public API which can then be statically checked by the compiler. This allows the difficult problem of determining whether an entire codebase is sound, memory-safe, and free of undefined behavior to be factored into many smaller, more tractable problems of verifying that individual components are sound given their APIs. You can even do this with wrappers and bindings to C libraries, and there are many examples of this in the Rust ecosystem.
Wins are often incremental. It's much better to start with the potential of guaranteed safety, sidestepped by a manual (opt-in) sacrifice of it in favor of getting something working, and slowly chipping away at the unsafety over time; than to start with the dispensation of safety as an institution altogether (C/C++) and hope that someday you can work your way to safety.
Put another way, as a developer, I'd much rather be part of a project using a language that is safe by default, which opts in to the unsafety it needs yet which hopes to someday simply remove all the `unsafe` keywords, than one that hopes to stumble its way to safety through relentless trial and error, testing, bug reports, debugging, etc. and has no actual measure of its level of safety.
On top of that, if you only use, say 10% of one of those libraries, you can easily wrap the 10% of that library in a safe fashion instead of waiting for 100% of the library to have its own safe wrapper.
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.
"- 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."
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.
> 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.
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.
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.
Thanks a lot for your reply. I admit I didn't check the details of the mentioned situation and, as you said, it was a long time ago, nor was my wording correct. Great to hear the financial situation is not dire.
I also admit I haven't been following Ardour progress for some time, so my judgement wasn't fully informed. By "powerful" I meant not getting in the way and providing the wide set of tools. I mostly do mixing and editing, and I stand by my words that Reaper provides the most flexible and advanced workflow compared to Pro Tools, Logic and Studio One specifically, if you take the possibilities of 3d party enhancements of scripting/plugins. This doesn't mean it's the "best" DAW, as one doesn't necessarily want that, but for me it beats the mentioned competition hands down.
It's definitely time for me to try Ardour again, though!
The problem with talking about DAWs and workflows is that there are so many distinct workflows that it becomes almost meaningless.
Watch a discussion between e.g. an Ardour user and a Reaper user about how to do something, and it will often seem like they are in different worlds. "Well, I would never even begin to do it that way" will almost certainly come up.It would be even worse if you listen to, say, a Logic user and an FL Studio user. So many "basic concepts" that one of them uses every day, but that don't even appear on the other user's radar.
That means that a given "most flexible and advanced workflow" that matters a lot one user will probably be awkward for another, but it won't matter to most people, because they do it a different way.
Like I said, I'm glad for DAW users that there are so many choices, and I'm fairly sure that for the vast majority of people, there's one out there that will make them happy. What it is matters much less.
> It doesn't even get into the modulation ballpark that Bitwig is playing in
I don't know if that's true. You can do a lot of modulation in Reaper directly, by chaining native LFOs or other modulation sources.
Bitwig's UI is incredibly sexy and beautiful, and Reaper is kind of ugly and crude, yes. That makes it easier in Bitwig to just see what's happening, whereas in Reaper you have to hunt down inside effects' parameters. I think that's the main difference.
But I don't think there are things you can do in Bitwig that you can't do in Reaper for a comparable amount of work. I'm not proficient in Bitwig, though. I would enjoy to see some comparisons.
manage complex routing schemes for your projects just dragging nodes and noodles.
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.
> 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.
ardour.org has money in the bank right now. Make a proposal!
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!
> 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` 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 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!
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).
It's likely that there will be a wholesale renaming of data types in here, because "int62_t" is a little too generic, and at least one of our long term devs is strongly against builtin-like names (eg. timepos_t) for things that are actually our own objects.
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
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.
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.
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.
> One nice thing about Rust is that there's an excellent chance you can actually modify this code.
Chance of a random user being able to modify compilable code inside a DAW: essentially zero. Effect of language choice: essentially zero.
Real time code; threads; pure "classic" MVC; custom widgets everywhere; non-standard keybinding mechanisms; topological sorting; insanely complex effects of latency on the meaning of "time"; temporal representation ... these are just a few of the major conceptual features someone tends to need to understand to go delving around inside a DAW. Things are roughly as complex as a modern web browser, except plus the realtime component.
I guess I have to disagree Paul, even though of course you're the one with practical experience in this specific niche since I didn't write a DAW from scratch.
Since you compared it to a web browser maybe it's instructive to remember that a big reason Rust had initial traction was that Mozilla had tried, and failed more than once to make key improvements to some of the browser's thorniest concurrent code in C++ but using Rust made this practical at last.
C++ is horrible and I think you're under-estimating just how much difference that makes in this scenario for something like Ardour.
The thing is, something like Ardour doesn't need "key improvements to some of [our] thorniest concurrent code in C++". We're in good shape there (perhaps because the requirement that most of our concurrent code has to fit in with RT requirements pushed us to do better design work there).
We need to people more than anything to do workflow stuff (mostly GUI).
Some years ago, I did several talks where I touted the idea that us adding a web interface to Ardour, so the generation raised on the idea that programming means HTML+CSS+JS could go to town and do new cool things (or at least, create new "cool" UIs).
We've failed/chosen not to publicize the fact that we have a web interface now, but my position on this has changed. I was wrong about the web interface. I just don't think we're going to get significant numbers of new contributors no matter what language or development environment they could use. We have on the order of 100 contributors already, and I think that if we ever got to 200, it would be a miracle. Even 25 new contributors would be a change in our developer resources that would be game-changing.
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.
Yes. I do know this (in 2016 I recommended that OpenOffice should get 4.2 out the door pronto or accept that they are done and should gracefully shut down the project).
Most technical developments only unconsciously reflect their social contexts. And in most cases those are the greater needs of corporations. E.g. C and Javascript. Rust is deliberate about tying its social context to its technical development.
Much like open source, esp.the Linux kernel, used the social contract of legal licenses and information transmission to enable a cooperative world, except Rust foregrounds as a social movement and demands traction through technical superiority. It's an innovator in community standards. "You want quality code? You'll have to abide by our social rules." Its founders have read some philosophy. Similar to how every Linux install means less corporate power and less invasion of privacy, every Rust conquest such as this represents a threat to dissolve the entrenched hegemony of competition and individualism. See: https://www.rust-lang.org/policies/code-of-conduct
Can you ELI5 how the development of, say, C, reflects the needs of corporations?
Does every linux install mean less corporate power when, e.g. AWS runs on linux?
Can you explain what the rust code of conduct (which AFAICT can be summarized as "please be nice") has to do with competition and individualism? Can't I still be a competitive individual without being rude?
> Can you ELI5 how the development of, say, C, reflects the needs of corporations?
Sure, thanks for being interested. Note that I'm not agreeing or disapproving with Rust or with you. It's merely that I'm responding to why someone asked why the Rust community feels compelled to proclaim these types of territorial expansions and why most people don't get it.
I don't have time to ELY5, but you can start with C's inception at corporate-government behemoth AT&T and follow it to e.g. here:
>"Naturally, many (but not all) of these volunteers have day jobs focused on C++: They include compiler writers, tool builders, library writers, application builders, researchers, book authors, consultants, test-suite builders, and more.
>Here is a very-partial list of some major organizations involved: Adobe, Apple, Boost, Bloomberg, EDG, Google, HP, IBM, Intel, Microsoft, Oracle, Red Hat."
Contrast that with, say the Arduino/maker movement... when was the last time they proposed language and standard changes? Although both communities use C, one of them is blinking LEDs in young couples' living rooms and the other is flying helicopters to protect borders which requires massive investment and coordination across hostile, competitive, captialized entities.
> Does every linux install mean less corporate power when, e.g. AWS runs on linux?
No, not always absolutely everything is always completely absolute all the time, forever, but you can contrast AWS running Linux with AWS running Windows and see development they do under e.g. GPL license must be shared back to the community.
> Can you explain what the rust code of conduct (which AFAICT can be summarized as "please be nice") has to do with competition and individualism? Can't I still be a competitive individual without being rude?
It's helpful to them when outsiders glean superficial meanings from the conduct such as that. No offense: We all want to feel warm and fuzzy. It's what they don't say. Take a closer look:
> Everyone is invited to discuss the proposal, to work toward a shared understanding of the tradeoffs. Though sometimes arduous, this community deliberation is Rust’s secret sauce for quality.
Their values prevent geniuses like Stallman from going rogue and embarrassing them socially. This is their tradeoff for the excluding contributions of embarrassing wizards and why it's so valuable for them to capture technical territory.
> We will exclude you from interaction if you insult, demean or harass anyone.
They will accept an inferior development if it means they can keep their reputation pure.
> Can't I still be a competitive individual without being rude?
Yes you can, but that's the contrapositive of their Code. If you are rude, your competitive contributions are excluded. So it's not "please be nice." It's "if you're not nice, you're not a part of us." Since this makes it harder to get the best people, it's a victory when they're able to pull of large technical feats.
The design mockups have a similar vibe to Bitwig.the color scheme and general ui (https://www.bitwig.com/). I say that as a good thing, I really like Bitwig.
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.
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.
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?
It's called fully-featured only in the design doc, so it's a statement of intentions. Te main repository page clearly states it's "still in the early stages of development".
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.
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
I wish you good luck! This is a very ambitious project.
Just one word of advice based on my own experience: open source projects for creatives are a peculiar niche. Success isn't really based on technical merit or usability. The project with the best marketing often takes it all and leaves barely any breathing room for competing projects.
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.
>Non-Goals
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.