Slashdot Mirror


Linuxmusician.com Interviews LilyPond Authors

jcn writes "Chris Cannam talks to the authors of one of the best-known and most ambitious music programs for Linux, the LilyPond score engraving system. Unlike other typesetting software like Finale or Sibelius, LilyPond is not a score editor, it aims to use simple textual description of the music and turn it into the highest possible quality output, automatically. Han-Wen says: In my opinion, any file format that claims to be universal should have two properties: it should have an expressive structure, so other formats can be expressed in it, and it should be as lean as possible, so that converting from other formats amounts to removing information. I think that MusicXML fits neither. Ouch."

9 of 227 comments (clear)

  1. Article Repost by Anonymous Coward · · Score: -1, Troll

    One of the best-known and most ambitious music programs for Linux is the LilyPond score engraving system. Unlike other typesetting software like Finale or Sibelius, LilyPond is not a score editor, and it has no GUI -- instead it aims to start from a simple textual description of the music and turn it into the highest possible quality output, automatically.

    LilyPond is the result of several years of work by Han-Wen Nienhuys and Jan Nieuwenhuizen. In this extensive interview, Linux Musician's Chris Cannam talks to them about recent and future directions for the project.

    Chris: I recently found a file of music examples I had printed out from LilyPond, probably in 1998. The LilyPond printouts looked less professional than they would be today, but many of the capabilities of today's software were in place. What have you been doing for the last six years?

    Han-Wen: About five years ago we were working up to release 1.0. Our target was to have a usable program that could produce basic music notation, where we defined "basic" as "whatever is in our set of simple test pieces", and usable was "will not dump core, mostly."

    We succeeded, but of course it didn't work very well for things that weren't in our test-pieces. By that time, we were also reaching the bounds of what was possible in our model of notation, an object-oriented model, hard-coded in C++. So we decided to integrate the GNU's GUILE library, a Scheme interpreter which was specifically designed to extend programs. We spent the next two to three years refactoring our C++ code into Scheme functions. This resulted in a more flexible, more efficient and better maintainable program.

    "We knew what 'publication quality' engraving meant, and were determined to perfect Lily into producing that."

    The second big change was catalyzed by an invitation to join a workshop in Firenze, Italy, organized by Nicola Bernardini of AGNULA fame, then director of Centro Tempo Reale. At the workshop we met Nicola, a few top-notch engravers, and an editor for Universal Edition, an Austrian publisher that does a lot of contemporary music. We had the chance to discuss LilyPond with several experts. On the one hand, we were thrilled that they took us seriously, but on the other hand they pointed to several inadequacies in our output. We arrived back home a great deal wiser.

    We knew what "publication quality" engraving meant, and were determined to perfect Lily into producing that. Since we like hand-engraved music, we started reproducing simple pieces in LilyPond and comparing the output side-by-side. By doing close comparisons, we learned how music should really look, and we fixed all the deficiencies that we found.

    In anything that you write, there will always be a neat, simple, small idea that is obscured by crufty implementation, bad design or suboptimal algorithms. According to me, the real art of programming is recognizing the neat idea, and being ruthless enough to redo all the other bad bits. Since we're writing new code all the time, we also have continue to refactoring everything, and this how we have spent the last few years: coding new stuff, and refactoring old stuff.

    We also did a lot with the documentation. Some of our users complain about the current documentation, and they're probably right, but what we have now is light-years ahead of the manual a few years ago.

    Your website features an essay on music typesetting that is quite critical of other software, with an entertaining piece of bad typesetting from Finale. You make an effort to explain that it isn't just an exceptional example -- but surely if programs like Finale and Sibelius are so widely used by good musicians, they can't really be that bad?

    The default output of Finale is indeed shockingly bad, which is why almost all other vendors routinely compare their packages to Finale. Of course, that's why we use it too. The default layout of Sibelius is not very elegant, but at least it's usable. A Sibelius sample would be

  2. Cowboy Squeal by Anonymous Coward · · Score: -1, Troll

    Cowboy Squeal!

    props to popeye

    1. Re:Cowboy Squeal by Anonymous Coward · · Score: -1, Troll

      Interesting, But not as interesting as this!

    2. Re:Cowboy Squeal by Anonymous Coward · · Score: -1, Troll

      BWAHAHAHAHA! AAAAA HAHA HA HA HA HA HA HA!

      (pause for lameness filter to catch up)

      WAHAHA HA HA HA HA! HEE HEE HOO HOO AAAAAHHH!

  3. Yeah, right by ericdano · · Score: -1, Troll
    Yeah, This looks a LOT easier.....NOT!

    I'd like to be able to play music into it. According to the FAQ:

    "Automatic notation, so that means I can play the music, and then it rolls out of the printer?

    No. Our system assumes that the input data is available in an exact, abstract form. Printing music is difficult enough as it is, so we do not wish to add another problem. Translating what a human plays to exact form is hard. Even if you get the correct pitch data from a MIDI keyboard (as opposed to a sound recording), one has to get the rhythms correct. For example, how is a computer supposed to distinguish between a staccato quarter note and an eighth note? Moreover, how would you print a piece that you cannot play in such a system?"

    This is crap. Why bother? Why not push Sibelius or Finale to be ported to Linux??
    --
    It's either on the beat or off the beat, it's that easy.
    I moderate therefore I rule!
    --
  4. MOD PARENT UP, +5 BONAR by Anonymous Coward · · Score: -1, Troll

    Are you mods gay or something?

  5. There's no need for this, thank god by Anonymous Coward · · Score: 0, Troll

    Talented and creative people use Macs, or Windows at a pinch. I shudder to think at the potential deluge of anime soundtrack remixes that would be unleashed by the releasing of production software to the sweaty, overweight and unshaven Linux hordes. Thank fuck for profit motives.

  6. XML'eske = Bloat by Anonymous Coward · · Score: -1, Troll

    Mod me down all you wish, however this is yet another case where we can see that XML is simply equivilent to bloat. We waste bytes storing useless tags, rather than develop a robust binary format which will be quicker to transfer, and allow more storage. Another great example of this is SVG, graphic files were never meant to be human readable - so why bother promoting a format that encourages this.

  7. ARTICLE IS SLASHDOTTED by Anonymous Coward · · Score: -1, Troll

    Music Typesetting on Linux: The People Behind LilyPond
    By Chris Cannam
    One of the best-known and most ambitious music programs for Linux is the LilyPond score engraving system. Unlike other typesetting software like Finale or Sibelius, LilyPond is not a score editor, and it has no GUI -- instead it aims to start from a simple textual description of the music and turn it into the highest possible quality output, automatically.

    LilyPond is the result of several years of work by Han-Wen Nienhuys and Jan Nieuwenhuizen. In this extensive interview, Linux Musician's Chris Cannam talks to them about recent and future directions for the project.

    Chris: I recently found a file of music examples I had printed out from LilyPond, probably in 1998. The LilyPond printouts looked less professional than they would be today, but many of the capabilities of today's software were in place. What have you been doing for the last six years?

    Han-Wen: About five years ago we were working up to release 1.0. Our target was to have a usable program that could produce basic music notation, where we defined "basic" as "whatever is in our set of simple test pieces", and usable was "will not dump core, mostly."

    We succeeded, but of course it didn't work very well for things that weren't in our test-pieces. By that time, we were also reaching the bounds of what was possible in our model of notation, an object-oriented model, hard-coded in C++. So we decided to integrate the GNU's GUILE library, a Scheme interpreter which was specifically designed to extend programs. We spent the next two to three years refactoring our C++ code into Scheme functions. This resulted in a more flexible, more efficient and better maintainable program.

    "We knew what 'publication quality' engraving meant, and were determined to perfect Lily into producing that."
    The second big change was catalyzed by an invitation to join a workshop in Firenze, Italy, organized by Nicola Bernardini of AGNULA fame, then director of Centro Tempo Reale. At the workshop we met Nicola, a few top-notch engravers, and an editor for Universal Edition, an Austrian publisher that does a lot of contemporary music. We had the chance to discuss LilyPond with several experts. On the one hand, we were thrilled that they took us seriously, but on the other hand they pointed to several inadequacies in our output. We arrived back home a great deal wiser.

    We knew what "publication quality" engraving meant, and were determined to perfect Lily into producing that. Since we like hand-engraved music, we started reproducing simple pieces in LilyPond and comparing the output side-by-side. By doing close comparisons, we learned how music should really look, and we fixed all the deficiencies that we found.

    In anything that you write, there will always be a neat, simple, small idea that is obscured by crufty implementation, bad design or suboptimal algorithms. According to me, the real art of programming is recognizing the neat idea, and being ruthless enough to redo all the other bad bits. Since we're writing new code all the time, we also have continue to refactoring everything, and this how we have spent the last few years: coding new stuff, and refactoring old stuff.

    We also did a lot with the documentation. Some of our users complain about the current documentation, and they're probably right, but what we have now is light-years ahead of the manual a few years ago.

    Your website features an essay on music typesetting that is quite critical of other software, with an entertaining piece of bad typesetting from Finale. You make an effort to explain that it isn't just an exceptional example -- but surely if programs like Finale and Sibelius are so widely used by good musicians, they can't really be that bad?

    The default output of Finale is indeed shockingly bad, which is why almost all other vendors routinely compare their packages to Finale. Of course, that's why we use it too. The default layout of Sibelius is not very elegant, bu