Meadowlark, a DAW written in Rust
github.com
github.com
>Non-Goals
...
Non-4/4 time signatures and time signature changes
...
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.
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)"
If you cannot use the MVP of the software for your use cases, that doesn't mean it cannot be worthwhile for anyone else.
Edit: Sorry, meant this as a reply to GP
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.
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.
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.
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.
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).
>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!)
Great! Made any music in 6/8, or signatures other than 4/4?
That was supported in Notator back in 1990 (along with time signature changes mid-track IIRC).
>I just don't see how it's relevant
I specifically said why, right at the top of my response.
>If you don't want to see development effort wasted I hope you'll contribute to the project
A tempting idea, putting it on my list. See, there's value in these discussions!
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).
Seems like a whole lot of puff over nothing.
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.
* 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.
The freaking Fur Elise is 3/8, and it's the Stairway to Heaven of keyboardists.
This is a rather strange limitation for a DAW.
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.
> To keep the scope manageable with such a small team, we will NOT focus on these features for the mvp
(emphasis added)
Edit: This was under "non-goals" for the MVP. Completely understandable...
Disappointing that it assumes octaves though. There are important scales without them, e.g:
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.
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.
I suppose a solution here could to just ignore the octave part by having only a "single" octave.
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?
Super curious if this is not the case.
Though I'm thinking "fixing something that fundamental after the fact is going to suuuuck".
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.
Maybe it's more "See, Rust can, too!" type software?
Footnote: I have not done extensive research, hence the question.
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.
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.
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.
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.
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.
https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DESIGN...
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.
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.
atk, atkmm, aubio, autoconf, automake, bison, boost, cairo , cairo , cairomm, cmake, cppunit, curl, expat, fftw, flac, flex, fontconfig, freetype, gdk-pixbuf, gettext, glib, glibmm, gnome-common, gnome-doc-utils, gobject-introspection, gtk-doc, gtk-engines, gtk+ X, gtk+ Quartz, gtk+, gtkmm, gtk-osx-docbook , harfbuzz, intltool, itstool, jpegsrcva, libarchive, libffi, libiconv, liblo, libogg, libpng, libsamplerate, libsigc++, libsndfile, libtool, libusb, libvorbis, libwebsockets, libxml, libxslt, lilv, LRDF, lv, libgnurx , NSS, NSS-PEM, pango, pangomm, pcre, pixman, portaudio svn rev, raptor, rasqal, rdflib, readline , readline , redland, rubberband, serd, sord, sratom, suil, taglib, tar, termcap, tiff, util-linux , uuid , vamp-plugin-sdk, xz, zlib
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.
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.
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.
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'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.
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 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.
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.
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.
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.
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.
In Bitwig, almost any parameter of anything is both a modulation source and destination. This is not true in Reaper.
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!
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.
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.
ardour.org has money in the bank right now. Make a proposal!
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
* 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).
https://www.youtube.com/watch?v=EiwUN7hz6eU
Scene launching started working yesterday (on top of clip launching).
All of our music<->audio time conversion stuff now lives in its own library, called temporal
https://github.com/Ardour/ardour/tree/master/libs/temporal
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'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!
I feel like they're just going to be ripping out a lot of subsystems later due to poor planning
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.
Title is wrong. This is not a fully-featured DAW. It intends to be.
but locks cool. are there actual screenshot available? the notes editor looks fun. loved the one from fruity loops A LOT (awesome profram)
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.
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 wrote some thoughts down (and gots lots of comments) regarding open source vs. scripting here: https://discourse.ardour.org/t/is-open-source-a-diversion-fr...
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.
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.
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
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?
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:
https://isocpp.org/wiki/faq/big-picture#standardization-comm...
>"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.
Great but 'Does It Actually Work?®'
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.
If not, then no thanks and no deal.
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.
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.
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?
Apparently, the authors drank their own cool-aid.
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
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.