[HN Gopher] Meadowlark, a DAW written in Rust
___________________________________________________________________
Meadowlark, a DAW written in Rust
Author : ushakov
Score : 138 points
Date : 2021-11-02 14:52 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ehutch79 wrote:
| 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
| mpfundstein wrote:
| "proudly written in Rust" ... what is it with this Rust guys? lol
|
| but locks cool. are there _actual_ screenshot available? the
| notes editor looks fun. loved the one from fruity loops A LOT
| (awesome profram)
| tialaramex wrote:
| 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.
| SOLAR_FIELDS wrote:
| 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.
| tialaramex wrote:
| 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).
| PaulDavisThe1st wrote:
| > 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 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...
| chillingeffect wrote:
| 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
| tayistay wrote:
| 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?
| chillingeffect wrote:
| > 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:
|
| 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.
| [deleted]
| mejutoco wrote:
| 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.
| bambax wrote:
| They also mention Bitwig several times in the design document
| (and no other DAW), so it's probably their main source of
| inspiration.
| lowbloodsugar wrote:
| >"This project is still in the early stages of development.
| Please see below on how you can get involved."
|
| Title is wrong. This is not a fully-featured DAW. It intends to
| be.
| ZoomZoomZoom wrote:
| 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.
| nitrogen wrote:
| _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.
| PaulDavisThe1st wrote:
| > 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!
| bambax wrote:
| > _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.
| ZoomZoomZoom wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| gmueckl wrote:
| Well, if you want an open source DAW, there's Ardour. I don't
| use it, but it is fairly complete.
| BillyDM wrote:
| "- Are there any plans to have some user-facing API for
| plugins/scripting? Professional workflows vary widely and
| automation helps a lot."
|
| Yes, a scripting API is planned. The GUI is being designed from
| the ground-up to where every action will go through an event
| system, so script will be able to do pretty much anything the
| GUI can do.
|
| A lot of the backend components will also be separated into a
| separate repo under the RustyDAW project, allowing someone else
| to create their own DAW with their own GUI if they wish.
|
| "- How flexible the UI is going to be? Multi-monitor setups of
| different configurations are very frequent in studios, free
| docks and/or floating windows are very important."
|
| We're not too sure on this one yet, it mostly depends on how
| many features the GUI library we are using will get. We hope to
| have a GUI that is as flexible as possible.
|
| "- I see you mention sidechain routing, but it's unclear what
| are the plans on multichannel audio and, more importantly, the
| routing possibilities. I'd love to see some kind of node editor
| for this where you can visualize and manage complex routing
| schemes for your projects just dragging nodes and noodles."
|
| We are currently working on a complex audio graph in the
| https://github.com/RustyDAW/rusty-daw-audio-graph repo. This
| will hopefully allow us to support any kind of complex audio
| graph structure.
|
| So far this audio graph only supports mono and stereo audio,
| but we can easily add more ports for multichannel audio in the
| future.
|
| Beyond MVP we will likely add either a Live/Bitwig style
| horizontal rack, or a FL Studio Patcher style plugin for
| advance routing. It's still being decided on which one we will
| go with.
|
| * edit - fix typo
| StarBrilliant wrote:
| I don't understand the definition of "fully-featured".
|
| Can a software be called "fully-featured" before the development
| is even far from complete?
|
| Oh, obviously "fully-featured" doesn't include time signature
| support.
| kennywinker wrote:
| 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.
| ehutch79 wrote:
| Yeah, but this one is missing ALL the features.
| ZoomZoomZoom wrote:
| 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.
| [deleted]
| jcelerier wrote:
| 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.
| gmueckl wrote:
| 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?
| BillyDM wrote:
| 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
| tekstar wrote:
| In defence of the project, it doesn't look like the Github
| authors posted it to HN.
| [deleted]
| fxtentacle wrote:
| It's in the GitHub description, too: "An open-source and fully-
| featured Digital Audio Workstation, made by musicians, for
| musicians"
|
| Apparently, the authors drank their own cool-aid.
| rectang wrote:
| 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.
| gmueckl wrote:
| Aspirations are fine, but you need to separate aspirations
| from the status quo in your communications. The HN headline
| fails in that regard.
| sodality2 wrote:
| It doesn't seem like the person who posted it is the repo
| owner/maintainer...
| emerged wrote:
| So is me landing on Mars, but the buzz killers always call me
| out for announcing that I'm a fully featured Mars astronaut.
| ZoomZoomZoom wrote:
| 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"_.
| falcolas wrote:
| 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.
| johncoltrane wrote:
| 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.
| ironmagma wrote:
| 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.
| PaulDavisThe1st wrote:
| Here's a list of the libraries we use in the Ardour project.
| Let me know how the, what is it, "crate" situation is for
| these or equivalent libraries:
|
| 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
| ironmagma wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| ironmagma wrote:
| 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.
| PaulDavisThe1st wrote:
| ...sure. But then you start to lose one of the most
| talked-up benefits of Rust, "safety". Or am I missing
| something?
| glowcoil wrote:
| 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.
| ironmagma wrote:
| 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.
| BillyDM wrote:
| 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.
| drogus wrote:
| 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.
| falcolas wrote:
| _This_ website is for developers; the product feature page
| should be about the product, not the programmers.
| berkes wrote:
| Do you consider the README on Github a "product feature
| page"?
| falcolas wrote:
| No, but I do consider a "Design Document" to be a product
| feature page. It's full of product features (and non-
| features) after all (when it's not going on about Rust).
|
| https://github.com/MeadowlarkDAW/Meadowlark/blob/main/DES
| IGN...
| lijogdfljk wrote:
| 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.
| falcolas wrote:
| 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.
| acomjean wrote:
| 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.
| beepbooptheory wrote:
| from the design doc:
|
| >Non-Goals ... Non-4/4 time signatures
| and time signature changes ...
|
| Just curious from a software design perspective why this is the
| case. I would, naively, assume you build up software primitives
| that wouldn't assume a time signature, making it trivial to
| support whatever segmentation of time. Why not just have a pulse
| and divide it however is needed?
|
| Also I see nothing about OSC support, is 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.
| shams93 wrote:
| 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.
| evilc00kie wrote:
| 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".
| jb1991 wrote:
| That is an odd "non-goal" indeed, and also unfortunate; it's
| like making a painting app but not giving users access to basic
| colors.
| sabjut wrote:
| A closer analogy would be to only support static images
| instead of animations and to only support cartesian pixel
| grids with only 2 dimensions.
| royjacobs wrote:
| The document states this is a non-goal for the MVP, not a
| non-goal for the final product.
| romwell wrote:
| "Ability to make turns is a non-goal for the MVP of the car
| we're building"
|
| You can't record a cover of Queen's We Are The Champions or
| Somebody To Love without struggling with the UI if 3/4 is
| not supported. Or Blondie's Call Me. Or a plethora of other
| popular music.
|
| "Fully Featured (in our imagination)"
| royjacobs wrote:
| "Including a rear parking sensor is a non-goal for the
| MVP of the car we're building" seems to be a closer
| analogy.
|
| If you cannot use the MVP of the software for your use
| cases, that doesn't mean it cannot be worthwhile for
| anyone else.
| gmueckl wrote:
| 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.
| royjacobs wrote:
| Okay, you just want different things from this MVP than
| the developers want. That's fine.
| andrewzah wrote:
| 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.
| gglitch wrote:
| There might be language games at work here. '4/4 only'
| could be totally reasonable for an MVP from the
| perspective of the software developers, but not minimally
| viable from the perspective of a musician.
|
| Edit: Sorry, meant this as a reply to GP
| HelloNurse wrote:
| 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.
| gglitch wrote:
| 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.
| philipov wrote:
| 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.
| romwell wrote:
| How is this a "closer" analogy? I motivated mine.
|
| 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.
|
| [1] https://soundcloud.com/romwell
| royjacobs wrote:
| 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.
| romwell wrote:
| 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).
| royjacobs wrote:
| 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!)
| romwell wrote:
| >I do have plenty of experience using DAWs
|
| 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!
| techbio wrote:
| Or fixing headline widths to 60 characters plus "..."
| mrob wrote:
| >Do love first class support for non 12-TET!
|
| Disappointing that it assumes octaves though. There are
| important scales without them, e.g:
|
| https://en.wikipedia.org/wiki/Bohlen%E2%80%93Pierce_scale
|
| https://en.wikipedia.org/wiki/Gamma_scale
| BillyDM wrote:
| Interesting, I was not aware of any scales without octaves.
|
| I suppose a solution here could to just ignore the octave
| part by having only a "single" octave.
| PaulDavisThe1st wrote:
| 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.
| HelloNurse wrote:
| 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.
| BillyDM wrote:
| 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.
| Igelau wrote:
| As other pointed out, this is the list of non-goals they
| cleared out to make a minimal viable product.
|
| Though I'm thinking "fixing something that fundamental after
| the fact is going to suuuuck".
| lijogdfljk wrote:
| 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?
|
| Super curious if this is not the case.
| HelloNurse wrote:
| 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.
| gmueckl wrote:
| 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.
| kierenj wrote:
| 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...
| tekstar wrote:
| Only part of Money is 7/4, it switches to 4/4.. so you'd need
| time signature automation as well :)
| open-paren wrote:
| > Non-Goals
|
| > To keep the scope manageable with such a small team, we will
| NOT focus on these features _for the mvp_
|
| (emphasis added)
| beepbooptheory wrote:
| 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
| bambax wrote:
| This is quite weird and unfortunate.
|
| Also, does the world need yet another DAW? There are dozens of
| DAWs, some free, some not. Most of them are excellent; all of
| them let you use non-4/4 time signatures.
| xook wrote:
| Genuine question: How many are written in Rust?
|
| Maybe it's more "See, Rust can, too!" type software?
|
| Footnote: I have not done extensive research, hence the
| question.
| bambax wrote:
| 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.
| mcguire wrote:
| Audacity replacement?
| devilduck wrote:
| I think we don't need another DAW unless it is a very
| different approach from the current options.
| devilduck wrote:
| They don't even have support for non-4/4 and you are asking
| about OSC? Is this you flexing that you know what OSC is or do
| you actually imagine that is on the road map at this stage?
| PaulDavisThe1st wrote:
| 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.
| rvz wrote:
| > Proudly written in Rust(tm)
|
| Great but _' Does It Actually Work?(r)'_
|
| 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.
| BillyDM wrote:
| 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!
| PaulDavisThe1st wrote:
| Ardour author here.
|
| > 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!
| BillyDM wrote:
| You do bring up some great points.
|
| Yeah, I guess it is still FLOSS. It's just my personal
| opinion that having a paywall (or the appearence of one) for
| the majority of your users is a huge barrier to success and
| openness, no matter how small that paywall is. Not that it's
| a bad business model, it's just one that I don't want to use
| for my projects.
|
| I don't want to sound like I'm downplaying the acheivements
| of Ardour. It is definitely impressive, and I look forward to
| the MIDI workflow improvements! It's just from a workflow
| perspective (especially from an EDM perspective), Ardour
| isn't quite my cup of tea. I personally want to create
| something with a workflow akin to Live/Bitwig/FL.
|
| Yeah, your article on time keeping was a huge inspiration in
| our time-keeping system. We would definitely love your
| feedback on this! Currently I've designed it in such a way
| where we can easily swap out the actual internals of the
| `MusicalTime` struct if we find that f64 is not good enough.
| I'm aware it will indeed be a challenge when it comes time to
| support automation of tempo, time signatures, swing rythm,
| etc. That's why I seperated it into its own repo to keep it
| focused on the pure algorithm. (The repo is in rusty-daw-
| timeline btw).
| PaulDavisThe1st wrote:
| > Ardour isn't quite my cup of tea. I personally want to
| create something with a workflow akin to Live/Bitwig/FL.
|
| 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.
| BillyDM wrote:
| Oooh, that clip launching stuff looks nifty! I'll have to
| try it out.
|
| I'll also take a look at temporal. You definitely have a
| point when it comes to avoiding mistakes of the past.
| Your help and guidance is appreciated!
___________________________________________________________________
(page generated 2021-11-02 23:02 UTC)