• Started in 1996 as part of the GNU project
• Music Notation Program
• Text-Based (WYSIWYM)
• Heavily engraving-oriented

• Most commercial MNPs are "Scorewriters"
• WYSIWYG paradigm
• "Scorewriters" are to music what "word processors" are to text
• ...like MS Word
• Examples: Finale, Sibelius, Encore
• LilyPond is text-based
• ...like TeX
• text source -> LilyPond -> PostScript/PDF/SVG

{ c' e' g' e' }

\score { \new StaffGroup { << \new Staff = "one" { \oboi } \new PianoStaff << \new Staff = "two" { \cornib } \new Staff = "three" { \cornig } >> \new PianoStaff << \new Staff = "eight" { \violinoone } \new Staff = "nine" { \violinotwo } >> \new Staff = "ten" { \viola } \new Staff = "eleven" { \cellobasso } >> } \layout { } } \score { \unfoldRepeats \new StaffGroup { << \new Staff = "one" { \oboi } \new PianoStaff << \new Staff = "two" { \transposition bes \cornib } \new Staff = "three" { \transposition g \cornig } >> \new PianoStaff << \new Staff = "eight" { \violinoone } \new Staff = "nine" { \violinotwo } >> \new Staff = "ten" { \viola } \new Staff = "eleven" { \cellobasso } >> } } \paper { after-title-space = 5\cm top-margin = 0\cm bottom-margin = 0.5\cm left-margin = 2.0\cm paper-width = 22\cm }

• LilyPond project started out of frustration with computer-generated scores
• Based on thorough analysis of best classical engraved scores
• Main goal: Approaching engraved quality

J.S.Bach, Cello Suite BWV1007
Left: Bärenreiter, 1950; Right: Henle, 2000

Apparatus Musico Organisticus, 1690

Bärenreiter, 1950

H.Riemann, "Modulation"

Output from Finale 2003, "professional" notation software:

Flat collides with note Stem of the E flat too long Stem of the B flat too long Too much white space in the reprisa Rest too low But you will not consciously realize all this unless you are a pro engraver -- do not give the user the option to manually tweak these!

Bärenreiter:

Lilypond 1.14:

Lilypond 1.17:

(Almost) like an engraving!

• Project by Dr. Jiří Žůrek (Institute for Classical Studies, Prague)
• "Definitive", "academic", "critical" edition:
• (of Mædieval Gregorian plainchant - 16th century)
• with the "role model" publisher
• extreme demands on engraving quality - OK
• need for Critical Apparatus - X
• proof of "definitiveness" of the text
• variant readings in different primary sources
• page layout problems

• Mandatory in a definitive academic edition
• An ancient piece is conserved in several primary sources
• Primary sources may differ/disagree (scribal errors, alterations, degradation of paper, etc)
• Critical edition must systematize the variants of the text ("variorum"), and explain grounds for choosing one variant over others
• Practice established since Robert Estienne's edition of the Bible (1550)

(J.S.Bach, "6 Partitas", ed. Hans Bischoff: engraved, 1942)

Two reasons:

• No footnote functionality in LilyPond
• Too many variant readings:
• most of the page would be occupied by the apparatus
• disturbs the flow of the main music
• ok for scholar application, but unusable for performance
• vast majority of readers do not care about the apparatus

• The editor critically examines all the extant variants, distills the most pure form of the piece
• This "definitive" form, is the main body of the book
• The "variolecturae" go at the end of the book

• Typographical errors in (non-musical) text
• Inadequate facilities to mix text and music
• Unable to get help from the development community

Apparatus chosen to be endnotes =>
text and music examples must seemlessly flow:

• "Embedded score" facility in LilyPond
• as soon as the music fragment transcends one line, the result is undefined
• not just a bug, but a fundamental limitation in the internal API structure
• the idea of continuous text / music flow, not well-received by the community

• Standard format of the apparatus; a line break can not appear after a black number
• Paragraph sign can not start a line
• Special rules for Vertical Bar

• many separate bugs
• skyline vs. rectangle approximation
• incorrect estimation of stem length
• ??? how many more ???

• Upstream community shows zero interest in addressing these issues
• Very small development community
• Hard to start development
  • write-only maze of C++, Scheme, (lots of stuff happening at the "between" level), lex/bison, METAFONT, ...
  • Contributor's Guide provides no explanation how things work; refers to a dissertation which does not even apply to actual code
  • requires a lot of knowledge about digital typography
  • even fewer people also interested in music engraving

Patches hard or impossible to contribute back:

• even though deployed in production
• broken process of patch review
• takes more time to get the patch accepted, than what it took to develop the solution!
• "vendor tree" diverged significantly from "vanilla tree"

• contributing back
• Initial:
• segfault on long input
• broken topology
• syllable-note alignment for melisma
• further height-estimation improvements

• Paper to appear in MIT's "Computer Music Journal"
• Support for Rhombica Notation
• contributing back