Version control is difficult with binary file formats. If you use a general purpose version control system, performing a diff^[4] won't show you what notes or markup changed. If you use an application-specific version control system, such as the one included with Sibelius, you can only examine changes graphically; and you can't integrate with the the revision control system you may be using for a larger parent project without maintaining a duplicate versioning tree.

LilyPond relies on text input files, allowing you to use the same revision control system you use for all of your other projects.

Repeating music without having to copy it is awkard at best in WYSIWYG programs. Some programs have a feature that allows you to make a dynamically updated copy of a set of measures, but it is cumbersome and inflexible. Including music or music fragments from a single source in multiple projects is largely impossible.

LilyPond allows you to store music fragments in macro variables that you can reference multiple times. You can even selectively turn off decorations on each macro instantiation. For example, if the first appearance of a measure includes fingering, you can turn it off for the later appearances by defining a new macro that turns off fingering before referencing the original macro and turns it back on afterward. Including music in multiple projects is also easy, but requires you to think ahead with respect to how you organize your files and name your variables. I'll discuss this issue in the “how” section.

Generating multiple outputs from same source using commercial software is largely impossible. You generally have to maintain two separate files with different formatting.

With LilyPond (and my custom preprocessor), I can generate guitar music that uses roman numerals for positions and barres or arabic numerals without making any changes to the source file (cf. Llobet's Preludio (en re mayor)).

Part extraction is an inconvenience that essentially requires you to format a piece of music an additional time for each extracted part. There is no need for part extraction when using LilyPond. As long as you organize your project with different parts in different files—or at least different parts in different variables—you can generate a score for a subset of parts with little effort. Your parts are not tightly bound together. Therefore, they need not be extracted.

I also had concerns about the longevity and interoperability of the propietary file formats and found that MusicXML lost too much information to be a viable export format. As already mentioned, I wanted a text-based format that could be versioned using the same source code revision control system(s) I use for software development. Of course, it needed to produce professional-calibre output, but flexibility and customizability were higher priorities. LilyPond met most of my requirements and seemed to be able to be molded into doing whatever I needed via its embedded Scheme language or via preprocessing. All that said, LilyPond does not do “the right thing” out of the box (except perhaps for piano music). With respect to guitar notation, just like Sibelius, LilyPond requires a lot of customization—an issue I'll address shortly.

At the base of the library tree sits use.ily,^[5] which defines a custom \use function that includes a file only once if it has already been included. The standard LilyPond \include will re-include a file, which causes tremendous problems when you try to reuse music from different files—re-inclusions can blow the stack and crash the program. The \use function is automatically available to all source files by way of lyc, a compiler script that wraps the lilypond command with various options and preprocessing. Therefore, no source files ever use \include directly; they all use \use instead. The only use of \include is the statement dynamically inserted by lyc to include a common preamble that at the moment only consists of use.ily.

The next layer in the library tree is a common library, defining instrument-independent customizations, including custom markup functions, convenience macros, default layout and paper definitions, as well as numerous additional customizations. In some sense, the default settings in the common library file constitute a style (e.g., default margins, fonts, etc.), but I treat each piece individually and adjust staff size, spacing, and margins, on a per-piece basis. For a collection of works, I try to keep the styling parameters as consistent as possible. From there, the library tree branches into classes of instruments (e.g., strings) and then specific instruments (e.g., violin or guitar). For classical guitar, I have custom functions for rendering barre, position, and string indications as well as macros for right-hand fingering.

I use a build system based on GNU autoconf and automake which generates a GNU make Makefile. In addition to lyc, the compiler script I mentioned, I have written lydep, a dependency generator that figures out all of the dependencies for a given source file in a manner compatible with GNU make. That way, the Makefile can rebuild exactly what needs to be rebuilt when a given source file changes. For example, if a library file is modified, then all scores that directly or indirectly import that file are rebuilt. The dependency generator takes into account LilyPond \include directives and my custom \use directives.

Finally, I have written lygen, a tool that generates a .ly source file from a high-level description of the score implemented as a Lua^[6] table. For example, my score file for Lágrima looks like this:

As you can see, the file contains no LilyPond markup. All the music goes in Lagrima.ily, which I will describe in my discussion of namespaces in the next subsection.

Perhaps the most important practice to apply when using LilyPond is not to pollute the global namespace. Assign each element of your score to a variable and name all of the variables with a unique score-specific prefix. If you place music in the global namespace, you can't reuse it elsewhere. You'll notice the cryptic “g_tarrega_lagrima” assigned to the namespace parameter in Lagrima.ly.lua above. That's a namespace prefix. LilyPond has no notion of namespaces, requiring you to approximate them via variable naming conventions. If you write a bunch of scores and decide you want to collect them into a book or if you want to include music from one file into another, you'll find it won't work if you used global artifacts. You must avoid polluting the global state. Everything should be encapsulated. My Lagrima.ily source file looks like this (without the data):

Other than the \use, there are no directives at the global scope. Everything is assigned to a variable.

Another essential practice is to notate voices separately. Never use \parallelMusic. Because WYSIWYG programs facilitate entering music measure by measure—and when you transcribe a piece from lute tablature, for example, you tend to go measure by measure instead of voice by voice—I started using LilyPond with \parallelMusic. That was a big mistake. It took a very long time to convert all of that music to separate voice blocks. \parallelMusic doesn't work well with many LilyPond features, making a lot of things not work or simply render incorrectly. I didn't have the presence of mind to realize that if I wanted to enter music measure by measure easily, I could keep all of the voices in separate blocks and simply split my text editor into different editing regions, one per voice. Once I did that, entering music measure by measure or voice by voice was simple. I could see the notes for all the voices in a single measure at the same time.

Along with notating voices separately, you absolutely must number your measures with a comment preceding each measure. Otherwise, locating your place in a piece of music becomes difficult and version control diffs become indecipherable.

One of the worst aspects about Finale and Sibelius is having to adjust every little thing by hand. Right-hand fingering was rarely automatically placed pleasingly (LilyPond does much better) and good luck repeating a section of music elsewhere without the fingering without having to copy it. With LilyPond, you still have to make adjustments with \tweak, but it's clear exactly what you've adjusted manually and by how much. Also, when repeating a section of music somewhere, you can simply reference a macro variable. If you want to repeat the section without fingering, there's no problem. Just disable the fingering before the section and enable it afterward.