Hacker News Reader

Comment by beepbooptheory | Hacker News Reader

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.

View on HN

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.

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".

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.

Or fixing headline widths to 60 characters plus "..."

The document states this is a non-goal for the MVP, not a non-goal for the final product.

"Ability to make turns is a non-goal for the MVP of the car we're building"

You can't record a cover of Queen's We Are The Champions or Somebody To Love without struggling with the UI if 3/4 is not supported. Or Blondie's Call Me. Or a plethora of other popular music.

"Fully Featured (in our imagination)"

"Including a rear parking sensor is a non-goal for the MVP of the car we're building" seems to be a closer analogy.

If you cannot use the MVP of the software for your use cases, that doesn't mean it cannot be worthwhile for anyone else.

There might be language games at work here. '4/4 only' could be totally reasonable for an MVP from the perspective of the software developers, but not minimally viable from the perspective of a musician.

Edit: Sorry, meant this as a reply to GP

Unfortunately, naive assumptions tend to bite later when the amount of rework needed to remove them is discovered. Being able to change time signatures is the sort of feature that is more important than delivering an anemic DAW sooner, and not only in theory as a "nice to have" but as proof of being able to be better than the competition.

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.

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.

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.

Okay, you just want different things from this MVP than the developers want. That's fine.

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.

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

I'm not sure why the amount of audio production experience is relevant in this case. I also don't have a horse in this race. I just find it curious that you seem to be so extremely passionate about taking a random item in a _design_ for an _MVP_ and drawing all sorts of conclusions about both the tool and the authors of this tool. Why does it matter so much that it doesn't align with what you find the most important aspect of an MVP?

Again, this is even just a _design_ for an MVP. If it doesn't align with what _you_ find important then that's fine. Just use something else, you've clearly been doing so for about 15 years. I hope you've enjoyed working on your songs, just like the authors of Meadowlark are enjoying working on this DAW.

TL;DR: you don't have experience in the subject you opine on, but wonder why someone who does would.

I'll address these points below.

---------

>I'm not sure why the amount of audio production experience is relevant in this case.

Because that's what would make you qualified to have an opinion on the matter, or make an analogy.

If you don't use a DAW regularly to make music, you are not qualified to say that lack of 3/4 support is just like having no parking sensor.

You don't have an understanding of which features are important if you are not a user. (Speaking of which, I hope you at least drove a car!).

>I also don't have a horse in this race

Well, you commented on the issue. There's your horse.

>I just find it curious that you seem to be so extremely passionate

As a musician, yes, I'm so extremely passionate about the art and craft of music making - and the tools involved.

Just like literally any other musician. We are passionate because music is how we express passion.

On top of it, I get sad when people express unsubstantiated opinions when confidence on the issues that I care about.

>Why does it matter so much that it doesn't align with what you find the most important aspect of an MVP?

Why does it matter to the developers to say that this is a project "by musicians, for musicians"?

For the same reason, it matters to me, as a musician, to note that their MVP is not heading in the direction of their claim.

If anything, I'm helping that project by consulting them on the product / giving user feedback on the design.

Because I care, and I don't want to see a development effort wasted on something that people won't use because the developers did not understand the needs of the people they are writing this program for.

>I hope you've enjoyed working on your songs, just like the authors of Meadowlark are enjoying working on this DAW.

Well I'm not posting my songs on HackerNews in a post saying "Background Music To Write Code To: By Programmers, For Programmers". That would be dishonest.

It makes sense, therefore, for musicians to comment on the discrepancy of something aiming to be a "fully featured DAW" without having the most basic feature (but shooting for advanced stuff few people need).

If you don't want to see development effort wasted I hope you'll contribute to the project. I'm sure the authors will applaud and enjoy your passion.

>Well I'm not posting my songs on HackerNews in a post saying "Background Music To Write Code To: By Programmers, For Programmers".

Neither were the authors of the DAW, someone else posted it using this title.

(btw I do have plenty of experience using DAWs (going back to Notator on the Atari ST) and have been an amateur musician since childhood. I just don't see how it's relevant in a discussion about an aspirational MVP design. Thanks for assuming the worst, though!)

>I 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!

I'm also a music producer/sound designer and audio engineer.

Not being able to change the time signature isn't that big of a deal... Well over 90% of music is 4/4 and even other common ones like 3/4 can still be written in a DAW set to 4/4.

As a musician, I'd rather see them spend time working on some unique features rather than something niche that can be added on later (apparently somewhat trivially).

Seems like a whole lot of puff over nothing.

I once wrote a track where 4/4 changed into 3/4 mid-song, and then back in a beta DAW that didn't have a time signature track at the time (Energy XT2).

So while it's possible, it's also annoying. You can't use the DAW click, and clips don't align with (what the DAW thiks are) measures.

This is added friction, and you know what it did? It made me stay away from making music like that because I don't want to be clicking around the DAW when I'm making music, I want things to work.

Making the 10% use case annoying while prioritizing the 0.0001% use case (how much of music made today is microtonal?) does not result in a general purpose DAW.

>apparently somewhat trivially

As a software engineer, I can assure you that there is no such thing. The cost of changing something we a bottom level (and the grid in a DAW is such an object) is always high.

If it's trivial to add later, it's less than trivial to add now. If it's difficult to add now, then the project is dead in the water because 4/4 is, for all intents and purposes, hard-wired.

Either way, it's concerning either from product or engineering perspective.

Alright, I get it. Non-4/4 time signatures are in much higher demand than I originally thought.

* edit - I'm not trying to sound mean. I just want to make it clear for those who may have not read my other comments on this HN post.

I thought it was clear that these non-features are only for the MVP, not the released "1.0 version", but apparently I was wrong. The "final" 1.0 version will indeed have support for other time signatures. Although because demand is apparently very high, I will likely add it to the MVP as well.

The way I have this designed, it is in fact trivial to add other time signatures later. The backend code only uses musical time as a unit of beats, it does not care about measures. Measures are purely just a visual thing for the GUI. Yes there are special plugins that care about measure like drum sequencers and advanced arpeggiators, but neither of those things are planned for MVP, so it's not like we will have to "rewrite" them.

What is not trivial to rewrite is support for non-western scales and microtonal stuff, which is why those are being included in the MVP.

The title of this HN post was updated, it now has correctly removed "fully-featured" in the title. Neither I or anyone on the Meadowlark team made this HN post. We got publicity a lot sooner than we thought we would, so we weren't even fully ready to make a full public announcement on the project yet. The design doc is still somewhat of a draft.

Addendum: 6/8, etc might be under 10% of music, but it's played by well over 90% of musicians.

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.

why couldn't you record Call Me?

Because you'd have Hours Of Fun with all the drums being triplets if you want to sequence them.

4/4 with triplets, swung rhythms, etc are not supported by their design.

And while you can record things, editing becomes clunky when the grid isn't there for you. At that point, it's easier to re-record the part. Or switch to another DAW.

A closer analogy would be to only support static images instead of animations and to only support cartesian pixel grids with only 2 dimensions.

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".

>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

You seem to have found a significant weak spot: apart from the dubious approach of rejecting MIDI, ignoring OSC and reinventing the wheel, the assumption of octaves is very gratuitous and a net complication.

MIDI supports 127 different notes and it is the synthesizer's job to decide their pitch; likewise, a piano roll has a predefined set of notes, each with its own pitch.

It's therefore very unfortunate that they decide to be much less flexible than MIDI and represent notes as

> The octave of the note, stored as an i8. For example, in 12-TET, a value of 0 means the octave with root note C4, 1 is the octave with root note C5, -1 is the octave with root note C3, etc.

> The index of the note in the scale stored as a u16. For example, in 12-TET, a value of 0 means C, a value of 1 means C#, a value of 2 means D, etc.

clearly closing the door to flat identifier spaces like the MIDI note number and to more general representations of tuning with non-octave repeating intervals or with the pitch of every note.

Also interesting. Of course I'm open to feedback. I feel that's one of the big purposes of a design document is to discuss the design decisions.

My idea was if the tuning called for it, it would just ignore the "octave" part and use the u16 to have 64K available pitches that can be used. The actual tuning map is sent to the plugins in a separate message.

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.

Not just somewhat arbitrarily invented scales from the west ... in Byzantine musical culture, they do not have or assume the concept of "octave equivalence". That is, doubling the frequency of a sound does not, in classical Byzantine music, constitute "the same note". Byzantine musical culture is wonderful in so many ways. They rarely notate pitches, preferring to notate intervals, which as anyone who has ever tranposed a song from one western major scale to another will understand, is far more of a deep representation of a melody than pitches.

Yeah time signature is more complex than you might think which is why a lot of hardware drum machines in the 80s could only do 4/4 or maybe 3/4 and 4/4 with their limited processesing.

> Non-Goals

> To keep the scope manageable with such a small team, we will NOT focus on these features for the mvp

(emphasis added)

I know, my question still stands though, I get that its not a goal right now, just seems like something you should be thinking about from the beginning

So strange! Very much add odds with the "full-featured" label. No Mission: Impossible theme (5/4)? No Pink Floyd - Money (7/4)? No Seal - Kiss from a rose? No Hey Ya!? Metallica - One / Nothing Else Matters? Fallin'?

Edit: This was under "non-goals" for the MVP. Completely understandable...

Only part of Money is 7/4, it switches to 4/4.. so you'd need time signature automation as well :)

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.

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.

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.

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.

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.

I don't know. Probably none. But I'm quite confident no musician or other user of a DAW cares what language it's written in.

If the goal is to demonstrate that Rust can be used to write that kind of software, then hey why not; but they will need to have users at some point, to be able to actually call it a DAW.

Audacity replacement?

Audacity (as it currently stands) is an audio file editor, not a DAW. Under its new management, it seems likely that it will evolve into something with many DAW features within a year or two.

Reply on news.ycombinator.com