用户邮件列表: lilypond-user@gnu.org

This mailing list is the main place for users to discuss and help each other.

lilypond-user subscribe and info

user archive1 archive2

注意:When asking questions, please use 小例子!

LilyPond 片断仓库

The LilyPond Snippet Repository (LilyPond 片断仓库) is a large collection of user-submitted examples, which can freely be copied and used in your own works. See what other people have written, and add your own!


Particularly instructive examples from LSR are included in our official documentation, in 片断.


Some level of support is provided on our IRC channel,


This channel has no public archive, so any question that may be useful for others would better be posted to one of the mailing lists.

irc name:


Spanish mailing list

German forum

Portuguese group

French mailing list

Dutch forum


LilyPond 报告

The easiest way to keep touch is by reading our community newsletter, the LilyPond Report:


发行版邮件列表: info-lilypond@gnu.org

This mailing list is a low-volume, read-only list which receives notifications of new releases.

info-lilypond subscribe and info

info archive1 archive2


开发者邮件列表: lilypond-devel@gnu.org

Most developer discussion takes place on this list. Patches should be sent here.

lilypond-devel subscribe and info

devel archive1 archive2

错误邮件列表: bug-lilypond@gnu.org

Bug-specific discussion takes place here.

bug-lilypond subscribe and info

bug archive1 archive2

注意:Before sending a message to the bug list, please read our guidelines for 错误报告.

Sensitive emails

Private matters should be sent to Graham Percival (project manager), who will discuss it with those concerned.


什么是 “小例子”?

一个小例子 (tiny example) is an example from which nothing can be removed.


  • The simpler the example is, the quicker potential helpers can understand it and help you.
  • A tiny example demonstrates that you have put effort towards solving the problem yourself. When people send huge portions of input, it looks like they don’t care if we help them or not.
  • Creating a tiny example helps you to understand what is happening. Many false problem reports can be avoided by attempting to create a tiny example; if you cannot replicate a “bug” in a tiny example, then the problem was probably an insufficient understanding of LilyPond, not an actual bug!


  • Include the \version number.
  • Make it small! Examples about spacing or page layout might require many bars of music, but most issues can be reproduced using less than a single measure.
  • When trying to create an example, try commenting out (% or %{ … %}) sections of your file. If you can comment something while still demonstrating the main idea, then remove the commented-material.
  • Avoid using complicated notes, keys or time signatures, unless the bug is about the behavior of those items.
  • Do not use \override or \set commands unless the bug is about those specific commands.
  • Optionally, attach an image showing the desired graphical output.

How tiny should they be?

Is the code below a minimal example?

\version "2.14.1"
\include "english.ly"

\score {
  \new Staff {
    \key d \major
    \time 2/4
    <cs' d'' b''>16 <cs' d'' b''>8.
    %% Here: the tie on the D's looks funny
    %% Too tall? Left-hand endpoint is not aligned with the B tie?
    <cs' d'' b''>8 [ <b d'' a''> ]

Well, it is not very big, but a truly minimal example is here:

\version "2.14.1"
  % middle tie looks funny here:
  <c' d'' b''>8. ~ <c' d'' b''>8

Very few tiny examples exceed 10 lines of code - quite often 4 lines are enough to demonstrate the problem!


If you have input that results in a crash or wrong output, then that is a bug.

第 1 步:检查是否已知错误

We may already know about this bug. Check here:


注意:Please DO NOT add bug reports directly to the bug tracker. Once an issue has been added to the tracker, feel free to add more information to that report.

第 2 步:创建错误报告

If you have discovered a bug which is not listed, please help us by creating a bug report.

注意:We only accept reports in the form of 小例子. We have very limited resources, so any non-minimal example will be rejected. Almost every bug can be demonstrated in four notes or less!

Here is an example of a good bug report:

% Accidentals should be printed for only
% the first note in a tie, but this version
% prints flats on both notes.
\version "2.10.1"

\relative c'' {
 bes1 ~

第 3 步:发送错误报告

Once you have verified that the issue is not already known and created a bug report, please send it to us!

第 4 步:等待回应

Once your bug report has been sent to the list, our Bug Squad will examine it; they may ask you for more information. You will be notified when the report will be added to the bug tracker. Please allow up to 4 days, as we have a limited number of volunteers for this task.

Once a bug has been added to the tracker, you can comment it to add more information about it. You may also mark the bug so that you automatically receive emails when any activity on the bug occurs. This requires you have a google account.


Once an issue has been added to the tracker, it can be very helpful if we can see the desired output. Feel free to add input code and/or images (possibly created with other tools) which demonstrate what you think it should look like!


We need you!

Thank you for your interest in helping us — we would love to see you get involved! Your contribution will help a large group of users make beautifully typeset music.

Even working on small tasks can have a big impact: taking care of them allows experienced developers work on advanced tasks, instead of spending time on those simple tasks.

For a multi-faceted project like LilyPond, sometimes it’s tough to know where to begin. In addition to the avenues proposed below, you can send an e-mail to the lilypond-devel@gnu.org mailing list, and we’ll help you to get started.

Simple tasks

No programming skills required!

  • Mailing list support: answer questions from fellow users. (This may entail helping them navigate the online documentation; in such cases it may sometimes be appropriate to point them to version-agnostic URL paths such as /latest/ or /stable/, which are automatically redirected.)
  • Bug reporting: help users create proper Bug reports, and/or join the Bug Squad to organize Issues.
  • Documentation: small changes can be proposed by following the guidelines for Documentation suggestions.
  • LilyPond Snippet Repository (LSR): create and fix snippets following the guidelines in Adding and editing snippets.
  • Discussions, reviews, and testing: the developers often ask for feedback about new documentation, potential syntax changes, and testing new features. Please contribute to these discussions!

Advanced tasks

These jobs generally require that you have the source code and can compile LilyPond.

注意:We suggest that contributors using Windows or MacOS X do not attempt to set up their own development environment; instead, use Lilydev as discussed in Quick start.

Contributors using Linux or FreeBSD may also use Lilydev, but if they prefer their own development environment, they should read Working with source code, and Compiling.

Begin by reading Summary for experienced developers.



In the past,

  • some users have paid for new features
  • some developers have added new features for hire

The LilyPond project does not organize such efforts; we neither endorse nor discourage such agreements. Any contracts between private individuals is the business of those individuals, not ours.


Any user wanting to offer money in exchange for work should bear in mind the following points:

  • LilyPond developers may advertise their services on the lilypond email lists from time to time.
  • Any agreements between private individuals should include the normal precautions when conducting business: who pays, how much do they pay, with what method of payment, and upon what set of conditions. We suggest that any ambiguity or uncertainty in these questions should be resolved before any work begins.

Interested developers

Here is a list of people who have expressed an interest in bounties. Note that the amount of work done by individuals varies quite a bit throughout the years. We do not guarantee that this list is up-to-date, nor do we guarantee that the people listed here have any ability. The only criteria is "XYZ asked to be listed on this page".

Looking at the git history is a good way to determine who the most active and experienced developers are. Statistics up to version 2.21.2:

overall historypast yearpast three months

Interested developers:

David Kastrup

Donations are required to let me continue my current fulltime work on LilyPond. I focus on user and programmer interface design, coherence, implementation, simplification, documentation, and debugging.


Development for LilyPond 2.21.2

注意:These are unstable development versions. If you have the slightest doubt about how to use or install LilyPond, we urge you to use the stable Download, and read the stable Manuals.

Release numbers 发行号

There are two sets of releases for LilyPond: stable releases, and unstable development releases. Stable versions have an even-numbered ‘minor’ version number (e.g., 2.8, 2.10, 2.12). Development versions have an odd-numbered ‘minor’ version number (e.g., 2.7, 2.9, 2.11).


Instructions for git and compiling are in the Contributor’s Guide.

lilypond git repository

Documentation writers and testers will generally want to download the latest binary:

GNU/Linux x86: LilyPond 2.21.2-1

GNU/Linux 64: LilyPond 2.21.2-1

GNU/Linux PPC: LilyPond 2.21.2-1

FreeBSD i386: LilyPond 2.21.2-1

FreeBSD amd64: LilyPond 2.21.2-1

Mac OS X x86 32-bit: LilyPond 2.21.2-1

Mac OS X PPC: LilyPond 2.21.2-1

Windows: LilyPond 2.21.2-1

Source: lilypond-2.21.2.tar.gz


LilyPond development is a fairly complicated matter. In order to help new contributors, and to keep the whole system (mostly) stable, we have written a manual for development tasks.



GSoC 2012

What is Google Summer of Code?

It is a global program run by Google that offers students stipends for working on open source software projects during summer vacations.

The LilyPond Team decided that this is an excellent opportunity to find new contributors and encourage students already participating in LilyPond development to become more involved. One of our contributors was accepted for 2012 edition of the program as part of the GNU project; we hope to participate in future editions as well.

Our 2012 Ideas List

Below is a list of projects that we suggested for GSoC 2012 students. Although the application period is over, we decided to keep this webpage online as an inspiration for anyone who is interested in developing LilyPond. Some members of the development team are willing to help people who would like to tackle these projects.

Of course, there are many more things to improve in LilyPond, including very small ones. A full list of all known issues can be found here.

Grace notes

Fix problems with synchronization of grace notes, together with all underlying architecture (see issue 34 in our tracker). Grace notes are confusing to LilyPond’s timing because they’re like going back in time. This causes weird effects, especially when one staff has a grace note and the other doesn’t.


Requirements: C++, MIDI

Recommended: familiarity with LilyPond internals

Mentor(s): Mike Solomon, Carl Sorensen


Adding comprehensive MusicXML export and improving import, together with tests checking that it works. Depending on time available, implement some or all of the following:

  • Handle basic musical content export like the MIDI export (i.e. using dedicated exporter classes, derived from the translator class)
  • Build the XML tree of the basic musical content, add a connection from music event to XML tag
  • Let all LilyPond engravers do their job
  • Add ability to link each output object (basically each stencil / group of stencils) to the music cause (and thus to the XML tag in the XML tree)
  • Add a XML output backend, which can then add the layout information for each output object to the XML tags

The goal will be considered achieved when a (previously chosen) score could be imported from MusicXML and exported back with no unintentional loss of data.


Requirements: MusicXML, Python, basic LilyPond knowledge

Mentor(s): Reinhold Kainhofer, Mike Solomon

Familiarity with other scorewriters (for cross-testing) would be a nice bonus.

Improve slurs and ties

The default shape of slur and tie curves is often unsatisfactory. Ties on enharmonic notes { cis'~ des' } are not supported, ties "broken" by clef or staff change aren’t supported well. The project includes collecting and sorting examples of bad output, deciding on the intended output and writing the actual code.


Requirements: C++, experience with writing heuristics

Recommended knowledge: LilyPond knowledge, aesthetic sense

Mentor(s): Mike Solomon

Adding special variant of font glyphs

Adding on-staff-line, between-staff-line, shorter and narrower variants of some glyphs, for example accidentals, together with a generic infrastructure to support them. An example is ancient notation breve notehead coming in two variants, with smaller and bigger hole.


Requirements: MetaFont, C++, good eye for details

Recommended knowledge: basic LilyPond knowledge

Mentor(s): Werner Lemberg

Improve beaming

Default positioning of regular, cross-staff, broken and kneed beams should be improved. Beaming should depend on context and neighbor notes (see section 2.2 here). If possible, reduce beaming computation time.


Requirements: C++, experience with writing heuristics

Recommended knowledge: aesthetic sense

Mentor(s): Mike Solomon, Carl Sorensen

Clean up various compilation warnings

Clean up compiler warnings, static code analysis, and valgrind warnings. Automatic code analysis tools (warnings in g++ and clang) and analysis tools like valgrind memory leak detection and callgrind code profilers provide valuable information about possible flaws in C++ code. Cleaning these warnings would allow us to automatically reject any patch which introduced extra warnings.


Requirements: C++

Mentor(s): Joe Neeman, Reinhold Kainhofer






Guido Aulisi, Joe Austin, Federico Bruni, Nathan Chou, Dan Eble, John Gourlay, Marc Hohl, Masamichi Hosoda, Mark Knoop, Tobias Kretschmar, Vincent Le Ligeour, James Lowe, Thomas Morley, Paul Morris, David Nalesnik, Keith OHara, Benkő Pál, Knut Petersen, Julien Rioux, Ben Rudiak-Gould, Devon Schudy, Heikki Tauriainen


Jay Anderson, Masamichi Hosoda, Abraham Lee


Simon Albrecht, Frédéric Bron, Federico Bruni, Colin Campbell, Urs Liska, James Lowe, Thomas Morley, Jean-Charles Malahieude, Patrick Schmidt, Pierre Perol-Schneider, Greg Swinford, Martin Tarenskeen

错误组 (Bug squad)

Simon Albrecht, Federico Bruni, Colin Campbell, Phil Holmes, Ralph Palmer


Simon Albrecht, Colin Campbell, Eluze, Marc Hohl, Phil Holmes, Marek Klein, Alex Loomis, Kieren MacMillan, Thomas Morley, Tim McNamara, Paul Morris, David Nalesnik, Urs Liska, Ralph Palmer, Pierre Perol-Schneider, Neil Puttock, Tao


Federico Bruni, Luca Rossetto Casel, Felipe Castro, Pavel Fric, Walter Garcia-Fontes, Tommaso Gordini, Erika Griechisch, Denes Harmath, Masamichi Hosoda, Jean-Charles Malahieude, Till Paala, Yoshiki Sawada, Tomohiro Tatejima, Paco Tomillo



Erlend Aasland, Maximilian Albert, Aleksandr Andreev, Guido Amoruso, Sven Axelsson, Kristof Bastiaensen, Pál Benkő, Frédéric Bron, Juliusz Chroboczek, Peter Chubb, Angelo Contardi, Vicente Solsona Della, Hajo Dezelski, Michael Welsh Duggan, David Feuer, Bertalan Fodor, Richard Gay, Mathieu Giraud, Lisa Opus Goldstein, Torsten Hämmerle, Yuval Harel, Andrew Hawryluk, Christian Hitz, Karin Hoethker, Rutger Hofmann, Marc Hohl, Bernard Hurley, Yoshinobu Ishizaki, Chris Jackson, Felix Janda, David Jedlinsky, Heikki Junes, Michael Käppler, Thomas Klausner, Marek Klein, Michael Krause, Jean-Baptiste Lamy, Jonatan Liljedahl, Peter Lutek, Andrew Main, Kieren MacMillan, Hendrik Maryns, Thomas Morgan, David Nalesnik, Matthias Neeracher, Keith OHara, Justin Ohmie, Tatsuya Ono, Benkő Pál, Benjamin Peterson, Guy Gascoigne-Piggford, Anders Pilegaard, Henning Hraban Ramm, Nathan Reed, Julien Rioux, Johannes Rohrer, Stan Sanderson, Andreas Scherer, Johannes Schindelin, Patrick Schmidt, Boris Shingarov, Kim Shrier, Edward Sanford Sutton, Adam Spiers, David Svoboda, Heikki Taurainen, Piers Titus van der Torren, Owen Tuz, Sebastiano Vigna, Jan-Peter Voigt, Arno Waschk, John Williams, Andrew Wilson, Milan Zamazal, Rune Zedeler, Rodolfo Zitellini


Tom Cato Amundsen, Marc Hohl, Chris Jackson, Alexander Kobel, Abraham Lee, Keith OHara, Carsten Steger, Arno Waschk, Rune Zedeler


Erlend Aasland, Trevor Bača, Alard de Boer, Colin Campbell, Jay Hamilton, Joseph Harfouch, Andrew Hawryluk, Cameron Horsburgh, Geoff Horton, Heikki Junes, Kurtis Kroon, James Lowe, Dave Luttinen, Kieren MacMillan, Christian Mondrup, Mike Moral, Eyolf Østrem, Ralph Palmer, François Pinard, David Pounder, Michael Rasmussen, Till Rettig, Pavel Roskin, Patrick Schmidt, Alberto Simoes, Guy Stalnaker, Arnold Theresius, Anh Hai Trinh, Eduardo Vieira, Stefan Weil, Rune Zedeler, Rodolfo Zitellini


Colin Campbell, Anthony Fok, Christian Hitz, Phil Holmes, Chris Jackson, Heikki Junes, David Svoboda


Alard de Boer, Federico Bruni, Abel Cheung, Frédéric Chiasson, Simon Dahlbacka, Orm Finnendahl, David González, Nicolas Grandclaude, Dénes Harmath, Damien Heurtebise, Bjoern Jacke, Matthieu Jacquot, Neil Jerram, Heikki Junes, Nicolas Klutchnikoff, Jean-Charles Malahieude, Adrian Mariano, Christian Mondrup, Tineke de Munnik, Steven Michael Murphy, Till Paala, François Pinard, Gauvain Pocentek, Till Rettig, Ludovic Sardain, Yoshiki Sawada, Thomas Scharkowski, Clytie Siddall, August S. Sigov, Roland Stigge, Risto Vääräniemi, Andrea Valle, Ralf Wildenhues, Olcay Yıldırım


我们写的有关 LilyPond 的文章

  • Server Acim. GNU/LilyPond (Turkish Language). 2013. (PDF 2100k).
  • Graham Percival. Sustainability in F/OSS: developers as a non-renewable resource. In Rencontres Mondiales du Logiciel Libre 2010 (RMLL2010), 2010. (PDF 333k).
  • Han Wen Nienhuys and Jan Nieuwenhuizen. LilyPond, a system for automated music engraving. In Colloquium on Musical Informatics (XIV CIM 2003), May 2003. (PDF 95k).
  • Han Wen Nienhuys. LilyPond, Automated music formatting and the Art of Shipping. In Forum Internacional Software Livre 2006 (FISL7.0), 2006. (PDF 1095k).
  • Margarethe Maierhofer Lischka & Florian Hollerweger. Lilypond: music notation for everyone!. In Linux Audio Conference 2013 (LAC2013), 2013. (PDF 890k).
  • Reinhold Kainhofer. OrchestralLily: A Package for Professional Music Publishing with LilyPond and LATEX. In The Linux Audio Conference 2010 (LAC2010), 2010. (PDF 767k).
  • Erik Sandberg. Separating input language and formatter in GNU LilyPond. Master’s thesis, Uppsala University, Department of Information Technology, March 2006. (PDF 750k).

大家怎么用 LilyPond 的

  • Kevin C. Baird. Real-time generation of music notation via audience interaction using python and GNU LilyPond. In New Interfaces for Music Expression, May 2005.
  • Alexandre Tachard Passos, Marcos Sampaio, Pedro Kröger, and Givaldo de Cidra. Functional Harmonic Analysis and Computational Musicology in Rameau. In Proceedings of the 12th Brazilian Symposium on Computer Music, pages 207–210, 2009.
  • Graham Percival, Tosten Anders, and George Tzanetakis. Generating Targeted Rhythmic Exercises for Music Students with Constraint Satisfaction Programming. In International Computer Music Conference, 2008.
  • Alberto Simões, Anália Lourenço, and José João Almeida. (J. Neves et al., editor). Using Text Mining Techniques for Classical Music Scores Analysis. In New Trends in Artificial Intelligence, 2007.



注意:Many old announcements and changelogs can be found in the Attic

New Italian mailing list

June 22, 2020 - All Italian users are welcome to join the new Italian mailing list, where they can get help and discuss about LilyPond in their mother language.

LilyPond 2.21.2 released June 21, 2020

We are happy to announce the release of LilyPond 2.21.2. This is a development version, but these are usually reliable. If you want to use the latest stable version of LilyPond, we recommend using the 2.20.0 version.

LilyPond 2.20.0 released! March 1, 2020

We are proud to announce the release of GNU LilyPond 2.20.0. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts.

This version provides a number of updates, including updated manuals. We recommend all users to upgrade to this version.