This is well worth reading for any developer once you get past the first page or so. At first the complaints about existing software seem overblown because it's not obvious where the shortcomings are, but once you get into it it's an interesting study in how multiple small flaws can be seriously aggravating to the trained eye...and the dangers of unthinking abstraction that works fine in simple cases but falls apart when applied to more complex problems.
I can barely see the difference even after the explanation; but it's a beautiful thing to watch perfectionists creating a truly great tool, and making it free. They really are making the world a better place.
>I can barely see the difference even after the explanation;
I'm only barely trained at piano - the handmade notation does look better to me, but I couldn't actually tell you why. Indeed my impression of the first close-ups was that they were pretty near identical, yet I couldn't get over the sense that one was richer, fuller. It would have been nice to have a blind study to open on - choose which of these x is the nicest rendered, state your musical training, then tell us why we like what we did.
Since typography relies on human judgement of appearance, people cannot be replaced. However, much of their dull work can be automated: if LilyPond solves most of the common situations correctly, then this will be a huge improvement over existing software. The remaining cases can be tuned by hand.
This is the thing that we so often forget: algorithms can take us a long way, but they can never completely replace judgement. Everybody should read this article, even if they couldn't care less about music notation. (I also particularly enjoyed the section on how not to design software.)
The care for detail here is overwhelming. Even if you care nothing at all about the content, it's a strong example of what can be achieved by striving for perfection.
I also find it interesting they turned to an algorithm similar to Knuth's TeX algorithm. "Minimizing ugliness" is a pretty potent computational metaphor for how detail oriented design work works, it seems.
Well, yeah, but the metaphor is what I think is interesting. It's technically nothing more than shifting from a deterministic to a statistical model, but the idea of applying statistical algorithms to many aspects where computers need to emulate human design is a powerful heuristic.
I have only fired up lilypond a couple of times, but I have to say I am very impressed by this open source project. It obviously aims to be best in category.
One sentence that struck me was "Notation is an intricate symbolic diagramming language for visualizing an often much simpler musical concept."
Now if you remove the word "musical", it's true of notation in general. Any notation should reflect the structure of the thing it is notating; if music notation is typically more complex than the "often much simpler musical concept" then I would say musical notation is broken and should be changed.
Is musical notation broken? I've no idea, I don't know enough about it to say.
From their point of view, it is much more complex than any given musical concept because it has to encode such a wide variety of musical concepts. The musician playing it doesn't (intentionally) pay attention to the complexities that Lilypad is talking about. (I've never noticed stem lengths or stem directions when playing, but they're important to keep things legible.)
It's comparable to fonts: the study of fonts is pretty intricate, regardless of whether you're writing a grocery list or "One Hundred Years Of Solitude".
This reminded me very much of the great effort that Knuth (as a commenter mentioned) put into both his monumental TeX formatting system and MetaFont font generation program in a (imho) successful attempt to enable the preparation of beautiful math documents.
One thing that made TeX so successful is that it was designed to be open, and many packages (e.g., LaTeX) have been written to made it easier to use and more powerful. If LilyPond can be easily extended in the same way (i.e., programed in LilyPond, not C++), it might be similarly influential.
I find it interesting they refer to notes as quarter values or eighths. I can quickly see myself getting confused by that (is that a quaver? Did I do it right?) - does it change if you change the time signature from 4/4 to 3/4? (forgive the slashes)
"Quarter note," "eighth note" etc. are the standard terms in US English. What you call a quaver, we call an eighth note, regardless of time signature. (4/4 time means there are 4 quarter notes in a measure; 3/4 means there are 3 quarter notes.)
When I looked at doing that many years ago, their attitude was that splitting it into a library was not a useful thing to do and that everybody should be editing text files.
Another problem is that lilypond is slow, and any WYSIWYG interface to it would either bypass the compiler to show a "preview" of the score or would have a horrible lag whenever the user edited something. This might not be obvious, but adding or removing (or even changing the pitch/duration of) a single note can potentially lead to a solution with completely different appearance (after all it's a dynamic programming algorithm that lays things out, considering all sorts of "badness" in the style of tex). If you remove this specificity for some greedy techniques, then it will no longer have lilypond's quality.
The performance would depend on how you interface with the library. I envision a setup where the entire piece is first written using a nice interface, that frontend then generates the text file that is passed to Lilypond, Lilypond does its magic (one time!), and then the user has an opportunity to make minor tweaks to the layout or start the cycle anew to fix mistakes.
Some people, like me for example, find it easier to edit the text files than to muck about with a mouse in a graphical editor, selecting or failing to select the note, selecting the note duration from a pallet or menu, seems to take forever - in Lilypond I would just type c4 d2 e4 and I am done. JEdit provides a good preview mode and integration if you require it.
However, the Lilypond input syntax could be improved a great deal - I don't think the multiple different types of braces used in syntax files should be necessary for example.
why is this not possible? Have the program read the "notes" from the finale file, format them into the lillypad format, and have its compiler spit the beautified version back out to you.
This would be the equivilent of building a "quick preview gui" for lillypad.
The point here is that grouping matters moreso than a simple stream of notes. If you just grab the notes as a stream (this is what happened to me the first time I used lilypond) you lose some of the control over what is considered voices.
...so the stream of notes is ~lossy~ compared to musically knowing that you're layering a repeating melody on top of a bass-line, or occasionally punctuating a melody with chords.
Well, don't complain then that they don't think your idea is a good idea and aren't going to spend their time (which nobody is paying them for) implementing it.
There's a huge difference between having to maintain a fork and just writing the extra features you want. No one has the right to insist that other people spend the time the way you want them to, but you can certainly complain about their choices being shortsighted.
I would like to see the usable GUI supporting all semantics from the text interface. Writing Lilypond notation compares to writing software, and we all know why programming is largely done with text and not with GUIs.
Meh, I was writing out scores for a band; when I started using Finale the musicians thanked me profusely for making it readable.
Unless you can afford your own personal copyist, it's sort of irrelevant. The little formatting nits you learn to work around (or just talk the musicians through it with pencils, which you end up doing anyway for musical reasons)
