Hacker News Reader

I can explain why I use tooling like this. I use Lilypond though, not Alda.

For me, it is very much just a markup for music notation that can be tracked in version control. Just like how one would write markdown and then generate html pages, I write Lilypond to generate scores.

Example workflow- I write a song, and use Ableton to capture it. I’m performing with real instruments, and creating arrangements without writing anything down.

Now I want to perform it with other musicians. I have a few options.

I can notate what I created by hand. I can use a proprietary graphical notation tool, which are expensive and generally have sub-par UX.

Or I can use a text-based system like Lilypond, and generate it. I can create reusable blocks, code snippets, look at a diff when I make changes, print the whole arrangement, print just the scores for individual instruments, adjust arrangements as easy as you adjust prose in a text editor.

And also, not have to think much about the presentation layer. Mature tools in this category like Lilypond output great looking scores.

Not the author, but a big fan of these kind of projects, which fall into a much larger community known as "Live Coding" (though it also applies to other creative persuits as well, music is probably the most common).

If the piano roll works for you, chances are these kinds of things won't. For me personally, the piano roll has never worked. Whilst I'm still trying to find my place within live coding, I've found trackers (especially Renoise) to be the best for me for the time being.

Where these projects really excel though is in algorithmic composition and generative music (modular synthesis is also quite well known for this), so rather than telling the computer exactly what to play and when, you define the rules and tweak them to change the results.

Of course they can also be used for a more traditional style of music as well, its simply another form of writing music for computers. Some people (most people) find the piano roll works for them, others prefer trackers and sequencers, others prefer code. Its purely preference at that point

> Sorry to be a downer here, but can someone explain to me what the appeal of these projects are?

I think for some people, the appeal is immediately obvious, and for others it isn't. If the appeal isn't there for you, that's OK. It just means it's probably not the right tool for you.

One of the things I find most fascinating about music-making is how varied and personal the workflows are, and how deeply those workflows affect the resulting music.

You aren't being a "downer" by not liking the sound of a tuba. It's just not your jam. But it certainly is for others and that's OK too.

Many of us are very fast with text editors and very expressive with algorithms but struggle with DAW interfaces. Text is just flexible enough to work as a replacement and the already existing tools to manipulate and manage it make it very attractive. Many of the things you pointed out could be handled with various editor macros or possibly even regex. In the case of programming languages, the high level information could be directly encoded by the author of the piece and the low level information could be generated dynamically.

It's a very different perspective on computer UI design and one I personally prefer, although I get why it's not for everyone.

> If I want to transport music notation between software programs, I have MIDI for that, which does a good job of capturing all elements of a performance (keys, timing, velocity, pedals, aftertouch, etc.) These types of notation formats almost always fail to achieve MIDIs precision across all the aspects of a performance.

Well put. A lot of these feel like the wrong tool for the job, and I have a really hard time understanding why you'd want to track pitch data in a format like this when, as you say, DAWs exist and midi tracks can be moved around between them.

The only time these types of projects make more sense to me is when they present opportunities for discoverability or non-linear sequencing that can result in new or interesting ideas. For example, the Orca Sequencer used in this demo vide](https://www.youtube.com/watch?v=Pe8wE0sx31Q) is an example of a tool that folks use as a synth-agnostic sequencer that takes advantage of a non-linear format to create music that you might not in a DAW/piano roll. Or at the very least, makes you take a wholly different route to get there.

Projects like Alda, however, make less sense to me since they are squarely pointed at linear-workflow music tracking, which is such a saturated space that it's hard to come in with a new format that doesn't just feel like a more painful way to do what a DAW can let you do.

For me the (more hypothetical than real) appeal is that if I actually get around to play with Markov chains and music, having an output target that is text-based (and well-documented) is a WHOLE lot easier than having an output that is one of "I programatically drive a mouse to click around" or "an undocumented binary format".

But, then, I also do close to 100% of my 3D-modelling in what looks like code.

For me, the question isn't "why do people like text-based description languages" it is "why do people dislike them".

And I guess the answer is "it doesn't matter, we are all different, and at the end of the day, what works for me may not work for you, and vice versa".

Heck, I even use both vi and emacs.

These projects appeal to those who think everything should look/work like simple code - basically hobby coding/tinkering with a bit of a musical excuse.

It's such a busy space, partly because these projects rarely bring anything new to the table. And if they do you end up with something that takes a long time to learn and has almost as much complexity as a real instrument.

So it's rare for either approach to get traction without some kind of championing by academia or industry.

>If I want to transport music notation between software programs, I have MIDI for that, which does a good job of capturing all elements of a performance (keys, timing, velocity, pedals, aftertouch, etc.) These types of notation formats almost always fail to achieve MIDIs precision across all the aspects of a performance.

Music notation works at a higher level of abstraction than that, and is intended to be intelligible by humans first and foremost.

Alright, it was wrong of me to call MIDI a notation format, since it's not.

MIDI is a protocol meant to be able to capture the performance of music, and much of the performance isn't human-intelligible data, so MIDI doesn't work as notation.

However, the case I was making is that MIDI can capture all the data present in a score already and transport between applications. No, you would never read MIDI itself from a file and try to play it on a piano, but I also doubt you could easily read Alda straight from a text file without rendering it either.

MIDI can capture the meaningful information about a performance of a work. It cannot work back from that and present the original sheet music. The performance is, by definition, only one possible interpretive expression of the written music. As such, MIDI cannot possibly transport all of the information of a piece of music that I score using classical notation without losing some of the specific information.

Yes that's a good point, something I was thinking about too after that post:

MIDI cannot work its way back to the original score itself, but it can capture a perfect performance of the score and allow that performance to be notated in another scoring program. That doesn't quite get you back to the original score however.

So now I suppose I can see some value in trying to develop more score representation formats with more compatibility - it'd be cool to be able to write a proper score then drag-and-drop it like MIDI into a DAW. Yes, that's usually possible through MIDI export, but it'd be neat if that was a first-class feature and we all passed around scores on the web instead of MIDI files.

EDIT: On further thinking, passing scores around wouldn't really be sufficient either, as oftentimes you do want a copy of an exact performance with humanized timings. I suppose you really would need to embrace both formats, or create some sort of hybrid that can capture elements of either/both freely.

This is a really nice and subtle point. A score, expressive as they can be, is still a text to be performed. No one performance is the text, and the text is not a performance. There is a whole person performing the work whose identity, personality, history, sensibility and present state of mind all feed into any specific performance.

To draw an analogy - we are more than happy passing around the works of Shakespeare in its textual form. But as we know, a good performance can bring so much more than is encoded in the text at face value.

Music is really just a non-verbal language. If you become fluent in the language, you can appreciate music in its textual form just like you can appreciate Shakespeare for its literary value.

To my mind, this is why notational representations still persist, even in the age of media recordings. That higher level of abstraction still carries plenty of value and its compactness (over performance) is convenient to creators and academics who wish to reference them with fast read access.

> Music notation works at a higher level of abstraction than that, and is intended to be intelligible by humans first and foremost.

there's an entire generation of people who mainly compose through ableton live's piano roll though

I misunderstood the point of this comment before, thinking you were arguing that MIDI fails because it is not, itself, a clear human-legible format like text-notation languages being discussed are.

I understand now that you likely meant that MIDI does not capture the score itself, so it does not work as a notation file format, whereas these text-notation languages do describe the score.

"If I want to compose music, I need a format that makes it easy to visualize and manipulate notes in context of the other notes playing across all instruments."

Most composers compose using a piano. Orchestration is something that generally happens later, after the song has already been worked out on one instrument.

I’m pretty skeptical of this statement, do you have a source I could check out?

I'm just going to concur with GP: as someone who has looked for advice for songwriting on guitar, the writers I look up to almost always wrote with a piano. If your quibble is with "most", and your musical tastes are somewhere within EDM (mine are not), might be a perception bias towards laptop electronica.

Me too. My brother in law would sit writing music on manuscript for hours. Very occasionally he would get up, go plink plonk .. mm .. plunk on a piano, and sit down to carry on writing.

I think the truth of that statement very much depends on the genre, workflow, and age of the composer.

Yes, some older composers cut their teeth with pianos, staff-paper and pencils and established workflows based strictly on getting the whole song on paper before the orchestration/arrangement, and still work that way today.

However, I'd argue the vast majority of younger composers and people who write in more electronic-influenced genres definitely do not follow that workflow. It'd be very hard to write an entire pop/rap/dance track that relies heavily on the drum and bass interplay by first writing it all out on piano.

i don’t know the breakdown but a lot of musicians in general do this, even some producers. For my genres more often with an acoustic guitar and vocalist (usually same person) ; interestingly at least one does this when the final song(s) don’t even include a guitar. I have very limited exposure to this but it makes sense.

https://woodandsteel.taylorguitars.com/issue/2021-issue-1/fe...

To put it another way, do you think that the harmonies and flourishes are written before the chord progression and the melodies?

Practically every single DAW setup has a piano keyboard sitting in front of it. As a guitarist, I have had to learn to be at least competent on keys to communicate with people using DAWs. That's a pretty strong counterargument.

I think the only real argument would be whether most people compose with piano or guitar--and piano outnumbers guitar by a lot last I checked.

Everything else is in the noise.

> Most composers compose using a piano.

Most of the time mountaineers use a mountaineering jacket to run errands in town when it's raining.

I'm not sure that measuring "most" has much explanatory power in either case.

Lilypond is quite good for transcribing music. It's compact and quick to write, so you can get the job done quickly, and the layout engine is actually good out of the box.

However, I once tried a (small) composition project in Lilypond, and it really slowed to a crawl when I started to make major changes to what I'd already written. The ability to "refactor" is just so much easier in a visual editor like Musescore or Sibelius.

Perhaps for more experienced composers, with less of a need for complete redos, tools like these are better at "getting out of your way".

For me, I think this is one of the coolest projects I've seen in a long time, and definitely the first musical programming language I've ever seen. I was a musician in high school and haven't picked up an instrument for a long time, but I still remember how sheet music works. As a drummer, I was never much good at reading notation or playing other instruments, so this would be a really accessible way for me to write music and see what it sounds like, as well as debugging it the way I would with code.

How about just using C?

https://youtube.com/watch?v=tCRPUv8V22o

Maybe /s, maybe not…

There is also the popular ABC music notation language, but it seems to be less comprehensive than OP

What I think this is trying to do is to put music composition at the reach of people who are used to REPLs and programming languages in general. But I agree with you that it is questionable if any of that makes any sense, since we already have fairly sophisticated software to compose music using notations that are much easier to handle (traditional staff, piano and guitar interfaces).

> If I want to compose music, I need a format that makes it easy to visualize and manipulate notes in context of the other notes playing across all instruments. DAW piano rolls do a fantastic job of overlaying note information, and traditional combined scores do the same too. Again, text notation usually falls flat here

Text notation is keyboard entry friendly, and version control friendly. Systems that support it will often render it to something that is more convenient for viewing, often as you edit or on save (e.g., there are VSCode extensions that render scores from LilyPond and ABCNotation; for LilyPond, there’s also support for navigating into the source from the rendered score.)

Dude, to me it sounds like you are missing the point of music, which is that there isn't a point. It is just to experiment and do whatever feels good for you, which can be quite different things for different people.

You're making me wonder if there's any drawbacks to ABC format which seems fairly compatible with MIDI? (via abc2midi & midi2abc commands)

I've played with ABC / ABC.js to render sheet music in the browser before and I like it for transporting notation; but I don't think it fulfills the same use-case that Alda is attempting to hit.

The main drawback of ABC notation is that it doesn't capture polyphonic music well but by the looks of it, Alda's notation doesn't either. You can write polyphonic music in ABC but it is clumsy. Another drawback is that the ABC language has warts and has accumulated some cruft. Which is to be expected since the notation was invented in the 1980's and have been incrementally improved since. The main advantage of ABC is that tens of thousands of songs have been notated in the format and that it is well-supported by lots of programs.

> The main drawback of ABC notation is that it doesn't capture polyphonic music well but by the looks of it, Alda's notation doesn't either.

Do you happen to know any good textual notation for polyphonic composition?

Due to the nature of the data, it is very hard to create good textual representations. The most practical I have seen are piano rolls and MIDI event notation.

ABC is very well optimized for single voice traditional instrumental music. In that domain (and with a bit of experience at it), it's very easy to write and read ABC:

  T:The Three Smokestacks
  M:4/4
  L:1/8
  C:Solomon Foster
  R:Reel
  K:G
  EF|G2BG FGAF|GBdg ecAF|G2BG FGAF|GEFD EDEF|
  G2BG FGAF|GBdg ecAF|G2BG FGAF|GEFD EDEF||
  GBdg e2ef|gefd edBA|GBdg e2ef|gefd e2dB|
  GBdg e2ef|gefd edBA|Beed efgf|ecAF GFEF|

The header L: field defines the default length of a note. In the body of the tune, uppercase letters A-G are notes in the octave that starts with middle C, lowercase letters a-g are notes in the octave above that. A number following a note name is a multiplier for the note length. Bar lines are pipes.

The drawback to ABC is as you wander away from that original use case, it gets harder and harder to use. Here's snippet of an arrangement of Sleigh Ride I was working on a few years ago:

  z +mf+ (+accent+e .^d/) z/ z|(+accent+e .d/) z/ z +p+ .^F/.=G/||[K:G bass octave=-1] +crescendo(+ .A .A .A .A|.A .A .A .A|+f+ +crescendo)+ +accent+ d zz +sfz+ G|

Studying it again, I can mostly figure out what it is trying to do -- z is a rest, things surrounded in +s are extra commands, so +p+ and +f+ are dynamics, +accent+ puts an accent over the next note, etc. It's still pretty easy to understand, but I'd have a hell of a time playing the music from that notation. And I coded up that ABC, if someone else had done it there's a decent chance I'd have to stop and look up some of their notation in the ABC standard.