Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meadowlark, a DAW written in Rust

github.com

Post reply on HN
Print view View original

61–70 of 124 posts

Re: Meadowlark, a DAW written in Rust

#61

Post by gmueckl »

lijogdfljk wrote: post #24
beepbooptheory wrote: post #2

from the design doc: >Non-Goals ... Non-4/4 time signatures and time signature changes ... Just curious from a software design perspective why this is the case. I would, naively, assume you build up software primitives that wouldn't assume a time signature, making it trivial to support whatever segmentation of time. Why not just have a pulse and divide it however is needed? Also I see nothing about OSC support, is th…

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 significan…

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.

Re: Meadowlark, a DAW written in Rust

#62

Post by gmueckl »

ZoomZoomZoom wrote: post #11

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 var…

Well, if you want an open source DAW, there's Ardour. I don't use it, but it is fairly complete.

Re: Meadowlark, a DAW written in Rust

#63

Post by HelloNurse »

mrob wrote: post #22
beepbooptheory wrote: post #2

from the design doc: >Non-Goals ... Non-4/4 time signatures and time signature changes ... Just curious from a software design perspective why this is the case. I would, naively, assume you build up software primitives that wouldn't assume a time signature, making it trivial to support whatever segmentation of time. Why not just have a pulse and divide it however is needed? Also I see nothing about OSC support, is th…

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

Re: Meadowlark, a DAW written in Rust

#64

Post by royjacobs »

gmueckl wrote: post #44
royjacobs wrote: post #37

Earlier quoted context omitted.

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

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…

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

Re: Meadowlark, a DAW written in Rust

#65

Post by ZoomZoomZoom »

bambax wrote: post #52
ZoomZoomZoom wrote: post #11

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 var…

> Reaper desperately needs a Free Software competitor But why? And why "desperately"? Yes Reaper isn't free (neither beer nor freedom) but it is cheap and extremely customizable, extensible, scriptable, and it works well on Linux (even on a Pi). It also has many non-free competitors and isn't dominant in its space in any sense of the word.

Of course it's not dominant by the market share, but it's the most powerful tool and it would be cool to have a healthy competition there. Reaper also has a vibrant community of scripters and their skills would be of some help for any free software DAW. The reasons are the risk of it being sold (unlikely) or, y'know, a "bus factor".

I have a huge respect for Ardour and its devs a lot, but unfortunately it's not even close. I suppose, Harrison income is minuscule. Thank god the development didn't cease some years ago when Davis wanted to step down, that would be a loss.

Re: Meadowlark, a DAW written in Rust

#66

Post by HelloNurse »

gglitch wrote: post #39
royjacobs wrote: post #37

Earlier quoted context omitted.

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

Re: Meadowlark, a DAW written in Rust

#68

Post by kennywinker »

StarBrilliant wrote: post #67

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.

I understood fully-featured to mean "intended to have a broad feature set".

There's no list of features that every DAW must have - so if you're going to be this literal I could easily argue that any DAW is not "fully-featured" because it's missing some feature that another DAW has.

Re: Meadowlark, a DAW written in Rust

#69

Post by HelloNurse »

lijogdfljk wrote: post #24
beepbooptheory wrote: post #2

from the design doc: >Non-Goals ... Non-4/4 time signatures and time signature changes ... Just curious from a software design perspective why this is the case. I would, naively, assume you build up software primitives that wouldn't assume a time signature, making it trivial to support whatever segmentation of time. Why not just have a pulse and divide it however is needed? Also I see nothing about OSC support, is th…

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 significan…

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.

Re: Meadowlark, a DAW written in Rust

#70

Post by andrewzah »

royjacobs wrote: post #64
gmueckl wrote: post #44

Earlier quoted context omitted.

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…

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.

Post reply on HN