Hacker News Reader

Comment by bijection | Hacker News Reader

For the intrepid, especially those annoyed with the purported input-sluggishness of musescore et al, an interesting text-based alternative is LilyPond https://lilypond.org/

My dad wrote an opera using LilyPond in vim, though I believe these days he's actually doing more with supercollider, which skips sheetmusic and goes right to sounds: https://supercollider.github.io/

View on HN

I love lilypond as a programmer because I can use git. I have a private git repo that has lead sheets for all my favorite jazz standards (with my own reharms), notation at various levels for my originals, arrangements of songs for my a cappella friends, and a cue for a full film score project I did. The output quality is amazing, but the best part is I don't have to worry about forward/backward compatibility. None of my old Sibelius scores are openable anymore without spending hundreds on an upgrade, but all my lilypond scores will always be available to me.

I use it for the same reason, but also it is worlds ahead of Musescore if you want to put together a songbook (particularly if you also have tex experience). The best advice Musescore has for making a songbook with many scores is to use a PDF editor on the output.

Also as a programmer, Lilypond is programmable, and nearly infinitely customizable (similar to tex). I love that I can write some style information in a "header" and include it in every score. In my current project I am writing a lot of SATB choral songs in book format. But I also want to do a melody only edition. Just tweaking a header file, I can hide all the other voices, no problem.

(I also use Musescore, which I prefer for composition or simple projects. But when I want to output a large finished product, I always go back to Lilypond.)

For the record, uncompressed MuseScore files ".mscx" are simply XML, and thus can be tracked in git if so desired.

This is good to know and technically correct. From a practical standpoint, text format is necessary but not sufficient for being usefully trackable in git. If you cannot efficiently diff and merge a format having the file in git gains you as little as having a binary file in git.

XML files are often of that kind, but not only. Many years ago I worked with a FORTRAN derived file format which from the outset should be ideal for git. In reality the files were several gigabytes and for most of them the ordering of the lines was insignificant[1]. Not only is git not particularly good with very large files (it certainly wasn't back then), diffing and merging files where several hundreds of millions of lines jump around arbitrarily is practically impossible.

[1] This was a deliberate design decision of the language. When it was conceived it was still usually punched on physical paper cards. One 80 character line used to be one punch card. Card decks sometimes fell to the ground and got all mixed up. A language that doesn't require a particular ordering of the cards (=lines) is kind of practical in real world scenarios. Of course millions of cards is not, so the point was kind of moot, but there we were.

I've created FileMonger exactly for that usecase. If score diffing is useful for people please send me an email at anything at https://FileMonger.app

I used to be big on LilyPond, but in the end I concluded that my musical brain works much more effortlessly when there's an actual graphical score in front of it. (Maybe I'd feel differently if I had one of those keyboardist/composer/jazz brains and/or perfect pitch.) Plug in a MIDI keyboard, learn the shortcuts, and input is fast enough in MuseScore.

There's definitely room for something that bridges the advantages of the different approaches, but it's a difficult problem and it's a $0 billion market, so having passionate people make MuseScore better is probably the best path forward.

After dabbling with LilyPond and MuseScore, I recently started trying out StaffPad for composition:

https://www.staffpad.net/

It requires a tablet and pencil/stylus, and it’s a bit pricey. But I’ve found the handwritten interface, once I got used to it, to be fairly intuitive.

Nice find, does it support drums? For handwriting.

Yes. You can both write notes for percussion instruments on a staff and apply preset drum patterns and fills. I don’t compose with percussion myself, and I don’t know how the drums and percussion in StaffPad might compare with other programs.

My still-early impression of StaffPad is that it is best for writing scores in a traditional, classical-like format, and detailed knowledge of standard music notation seems to be necessary. It might not be suitable for people who are more comfortable composing with keyboards, rhythm machines, digital audio workstations, etc.

I learned how to write music 50 years ago on paper. Compared to that, this software is a huge advance. Being able to edit scores easily and hear what I write played back is wonderful.

I agree with you that a graphical interface works better. All existing sheet music follow this same format. It seems strange that some are trying to go in a vastly different text based approach.

Also, there's Frescobaldi, which is essentially an IDE for LilyPond: https://frescobaldi.org/

LilyPond is incredible for the one purpose it's built for: engraving notated music. But music engraving is the usually the very last step of a compositional or editorial process. As such, other methods, even pen and paper, may well be superior tools for the creative process of composition (although we should also remember the testimony of Bach's sons that the elder Bach always composed away from the keyboard, and regarded the inability to compose without an instrument at hand to be evidence of poverty of invention; of course, this does not rule out the possibility that Bach tested out out his draft compositions on a keyboard).

On the editorial side, LilyPond is an incredible tool for creating modern editions of earlier music, specifically music in mensural notation. It comes with common glyphs and has full ligature support, and the separation of content and presentation means that one can reproduce the look of early manuscripts and prints while generating a modern score from the same source file. This has been really great at reducing transcription errors by easing the mental burden of transcription, transposition and note reduction, which can all be handled automatically by LilyPond. It's not perfect, but miles ahead of any alternative.

Bach had zero need to “test out” his music at the keyboard. He could hear it perfectly in his head.

> elder Bach always composed away from the keyboard, and regarded the inability to compose without an instrument at hand to be evidence of poverty of invention

What older people on the extreme of some skill think about the skill is not necessarily applicable to 99.9% of us.

I’m a beginner pianist, and I’ve been writing down stuff in ABC notation[1] using Obsidian[2] and a plugin[3] for instant previews. I was already using Obsidian for all of my plain-text Markdown notes, so it was the obvious choice for me. Obsidian also has a nice WYSIWYG-preserving PDF export feature in case I need some printed sheets. :)

- [1]: https://abcnotation.com

- [2]: https://obsidian.md

- [3]: https://github.com/abcjs-music/obsidian-plugin-abcjs

ABC is easier to learn but also not feature rich. ABC vs Lilypond is similar to asciiMath vs MathJax in this aspect. You'll soon find its limitation and needs more.

(But Lilypond is hard, harder than writing documents in LaTeX for example.)

And for the intrepid folks who prefer algorithmic or computer-assisted composition, there's Abjad, a Python-based wrapper around LilyPond.

https://abjad.github.io/

I'd been trying to find a way to "write" the music in a way more similar to how I think about it.

from this pursuit, I've come to realize that "sheet music" is just the only technologically available way to store the music back in the day. a practice which had an entire publishing and printing industry around it; this is how composers in the 19th century made money

BUT THEN, sound recording technology made that be somewhat obsolete, and then synthesizers and computers came and made music writing notation be less and less capable of keeping up the pace of musical technology innovation.

all in all, I'm considering that what if I say that PCM is a writing and start 'handing down music' directly as 0s and 1s in at a 16 bit depth (two bytes per sample) at a 44100 samples per second?

then again that's cumbersome, so the super collider code (and everything needed to run it) IS now the 'music notation' which includes a description of the instrument as well as the song/the music. (traditional written sheet music notation does not really include a description of the instrument beyond a reference by name)

this also "turns" the music interpreter into a digital to analog converter. lol

Csound is somewhere between using a hex editor on a PCM file and using the somewhat more abstract Supercollider gens.

au contraire.

CSound is akin to a badly written assembly language for audio synthesis and processing.

SuperCollider (or more precisely, SClang) is more like Lisp for audio synthesis and processing.

One important difference is that the designer of SClang understand roughly 1000% more about programming languages than the designer of CSound (who was a visionary person, but who really didn't understand programming languages).

Sclang has little similarities with Lisp, its biggest influence is Smalltalk! Or did you mean it somehow metaphorically?

PCM is an encoding of sound, not a composition.

A composition, to varying degrees depending on the composer, leaves various degrees of freedom for the performance. So the PCM encoding of a performance is entirely different to the composition ... conceptually.

However, a good musician may be able to listen to the PCM encoding (aka "digital audio") and from that frame their own understanding of the composition, thus leading to a new performance.

So .. it's complicated.

so PCM would be like the piece of paper without the musical staves? (to draw a direct analogy)

I am interested in music in contrast with the broader "sound art"; then again I don't even know what the heck this 'difference' between these even means

A good friend of mine used to be a core developer there. He started by nagging them about the horizontal alignment of notes in different instruments/voices and that blossomed to over a year of collaboration.

It's very much like with kerning - once you see a sheet with decent alignment, you can't unsee it.

When you say he wrote an opera using LilyPond in vim, do you mean to say that his setup for composing was a vim terminal? Or did he write a draft first on some other medium such as paper and then inputted that into vim?