LilyPond is an "automated engraving system." It will format music notation beautifully without requiring typographical expertise of its users.
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?
Modern computer printouts do not look nice: they have a bland, mechanical look. By contrast, we try to mimic traditional plate engraving in the general impression, layout algorithms, and the font design. Consequently, our output often beats our competitors when it comes to good looks.
Normally, one notices these details only subconsiously. The best way to become conscious of these differences is to compare a traditionally printed and a computer printed edition of the same piece, preferably with a magnifying glass. If you are not sure: traditional engraving is photographically reproduced hand-work, and can be recognized by slight irregularities in symbol placement, and small blotches due to the reproduction process.
Originally, music was printed by stamping and engraving symbols mirrored into metal plates. The plates were inked, and paper was pressed to it, yielding a left-to-right printing. Hence, professional music typography is now known as engraving, even when it is done with computers today. People who do this are called engravers or copyists.
We think that beautiful music deserves to be printed with a beautiful layout.
Good engraving helps to read the music, making it is easier to play from. For example, if the layout reflects the character of a piece, then it is easier to interpret. If it is tightly spaced, it will take less pages, reducing the number of page-turns. If a system (a “line”) has a unique horizontal layout, then it is more easily found back after looking away at the conductor. A part which is printed with heavy symbols and thick lines will be easier to read from a distance.
No. We give it away for free. Go to the download page.
No. Not only do we give it away for free, but we also deliver it with full source code, and permission to distribute, modify, sell or mutilate it. In other words, LilyPond is libre software; it is part of the GNU project, and distributed under the terms of the GNU General Public License.
We think that this is much more important than cost. It means that you have the freedom to fix, modify and extend the program, or you can pay someone else to do so. We will not force you to upgrade when your system is abandoned, and you are not lost when we abandon the program.
LilyPond is a compiler: the music is encoded in a .ly file. When LilyPond is run on it the input is transformed into music notation, which is written to disk as PostScript or SVG and postprocessed to PDF and PNG.
We have designed our own input format, the .ly format. It is a language that encodes music using expressions. These music expressions are composed of simpler music expressions, where the simplest expressions are notes and rests. This is analogous to how arithmetical expressions can be broken down in simpler expressions, where the simplest expressions are numbers, operators.
We believe that none of the existing formats address all these requirements. For example, MusicXML cannot be typed by hand, DARMS is limited in its application, ABC has no strict formal definition, and NIFF is binary. Nevertheless, this does not restrict you for using those formats: there are filters that convert from various formats to .ly.
Take a look at the tutorial. It is pretty short, chopped in easily digestible chunks, and we've spent a lot of time polishing it. If you like to learn by fiddling around, then you can get input examples, by clicking the music images in the tutorial.
We try to make LilyPond as good as possible, and that implies that we continually improve the input format. We change the syntax whenever we feel that it will simplify the language as a whole, or ease the learning curve. Keep in mind that the syntax is as great as it is now because we also did this in the past.
Most of the language changes can be handled by running the program
convert-ly, which is supplied with LilyPond. However,
convert-ly can only do its job if it knows what version the
original file was written for. Therefore, it is important to add
version statements to your files like this:
Changes that cannot be handled by simple edits are marked by a bump in the major version number: converting 1.8 to 2.0 files will need overseeing.
There is no single answer to this, as the time spent depends on the complexity of the music, and your fluency in LilyPond. Music with complicated constructs (cross-staff beaming, collisions) takes longer to enter than simple monophonic music. Experienced users have reported average times of 3.5 pages per hour for typing straightforward music monophonic with an editor only. This time includes corrections and minor layout tweaks.
There are other options: it is possible to create the music in another format. Supported formats include
musicxml2ly a
partial convertor from MusicXML, and Guido Amoruso's xml2ly
will convert MusicXML to LilyPond. (About MusicXML). We have no time to also make a graphical user interface. Luckily, other people have filled the gap. The following programs have competent LilyPond export functions and are actively being developed.
There are also different, non-graphical interfaces:If you have a binary package which does not install correctly, or if you have trouble while following the instructions, then send a full bug-report to our bug list. Of course you can also write to the lilypond-user list for help.
You can write to the lilypond-user mailing list (which is at http://mail.gnu.org/mailman/listinfo/lilypond-user). It is also a good idea to check the archives of the mailing list, which are at http://mail.gnu.org/archive/html/lilypond-user/.
If you have input that results in a crash or erroneous output, then that is a bug. Please help us by sending a good bug-report: an input file that will reproduce the problem. Please make it small, so we can easily isolate the problem. Don't forget to tell which version you use, and on which platform you run it. Send your report to bug-lilypond@gnu.org.
Sure! Read sponsoring for more about getting custom functionality.
It is a tempting to think that inventing the syntax solves the problem. In practice, less than 10% of the program is involved with handling input and the syntax. Almost always, adding features involves a lot more than syntax, and is also much more complicated.