About Me and my Stylesheet
William Rehwinkel
Introduction
Hello world! This is William, I’m an organist currently living in New Jersey and going to the Juilliard School for my master’s as a harpsichord major. For the many musical things that I enjoy doing, I do a lot of engraving, and Lilypond is the engraving tool that I always use. It is extremely versatile, excelling at a lot of different types of scores and engravings.
For my compositions, I am quite happy that Lilypond has managed to handle all of the quirks of organ compositions, including how to write registration changes and extra brackets between the staves (this will be explained below). I find that using Lilypond does not limit me in any way; anything from adding extra staves to more advanced notation that I experimented with (also see below) is possible.
For my editions of early organ music, I’m able to use a different set of Lilypond features to help me make my own feeble attempts at scholarly critical editions. I find that the way that I write the notes and arrange the text file lends itself well to when I’m in the transcription phase at the beginning of the process. Using git version control makes keeping track of changes and incremental drafts very easy. Lilypond makes it so easy to arrange the layout of the piece to have easy page turns. Lilypond also has many tools that I can use to note editorial changes (including footnotes), and I even created some myself using scheme (this will be discussed in a later blog post).
The pipe organ wiki that I operate uses score incipits which use Lilypond. The Lilypond text input is well-suited for the task (much more so than any GUI-based music editor). Not only is the text-based input inherently better because you can write it in-line and save it with the rest of the text on the page, but the way that Lilypond makes all of its features available to you while not cluttering the screen with all of them in a GUI means that I can be as specific or as basic with my input as I want. Even the most basic input such as
\relative c' { r16 c d e f d e c g'8 }
is enough to make a nice-looking incipit.
After switching from MuseScore around 2019, I’m very proud to be using Lilypond to create all these different types of scores. Every time the topic of notation software comes up I tell anyone who will listen about how great Lilypond and its engravings are, how it is definitely worth taking the extra time to learn how to use, and about how it is free (in every sense of the word) software that can’t be taken away from you in the future. Also, nowadays I’m quite happy to be active on the Lilypond mailing list where we help each other with our problems.
After hearing the recent engraving software news and seeing many people on various message boards show reluctance to switching to Lilypond (and MuseScore) for a variety of reasons, I was inspired to create this blog (the title is a reference to me and a few of my friends who also use Lilypond) to share my adventures around using Lilypond, talk about how I solved problems that were faced along the way, and be an example (hopefully a good one) of what is possible with this software. Hopefully this blog will not only help spread some “tips and tricks” but also inspire other people to think of Lilypond as more than a free lesser alternative to expensive paid-for software and give it a shot like I did years ago.
Organ manual brackets
Years ago, my dad told me about this notation software he found where you use text input and it generates the score. After looking into it, I decided to take the plunge and try it myself. At the beginning, it was so difficult; I had to use google to figure out how to do even the most basic tasks. And the files themselves were very badly organized; I didn’t use variables to separate the note-writing and arranging of the layout like I do now. Even though I thought that default Lilypond scores looked nicer than default MuseScore files, there were some things that I wished could be better. However, as I continued using it I found the Lilypond process to be more efficient compared to using a GUI.
At some point, maybe in 2022, I was wondering how I could replicate this thing that I would find in 20th-century printed scores: a square bracket that is used to group together different staves to tell you what manual to play each staff on. Anyone who has seen a Charles Tournemire piece published by Durand will know what I’m talking about.
After looking around, I could see that this wasn’t something that was supported in vanilla Lilypond. I considered using a cross-staff arpeggio for this, but I didn’t know if this would be the best solution. After this, I decided that I would ask the Lilypond mailing list about this, but before that I decided to quickly search and see if someone had asked this before.
Fortunately, someone had in fact asked about this very thing in the past. Even though there were some dead links in this 7 year old email thread, I did find someone who pasted the code snippet in the email itself. I took the code and ended up with this (later on, I added a second paremeter to change the X-offset of the bracket to deal with collisions with accidentals):
\version "2.25.19"
#(define-markup-command (openBracket layout props height offset) (number? number?)
(interpret-markup layout props
(markup #:line (#:with-dimensions (cons 3 0) (cons 0 0)
(#:path 0.10
(list (list (quote moveto) (* offset -1) 0)
(list (quote lineto) (- (* offset -1) 1) 0)
(list (quote lineto) (- (* offset -1) 1) (* height -1))
(list (quote lineto) (* offset -1) (* height -1))))))))
\score {
\new PianoStaff <<
\new Staff { <e' g' c''>2^\markup\openBracket #18 #0 }
\new Staff { \clef bass <c g >2 }
>>
}
For past me, this was a breakthrough moment. For the first time, I saw that, with the ability to use scheme code to accomplish my goals, anything was possible, no matter how hard it would be to figure out at first.
In Spring, 2024, my final semester at Oberlin Conservatory, I took a “Programming Abstrations” class, which among other things taught us the Scheme programming language. Thanks to this fortunate coincidence, I became more confident at reading the Lilypond source code and making my own bits of code. I felt more confident that I could read other people’s code excerpts and understand what they were doing, and how I could create my own in the future.
My stylesheet
After this, I started obsessing over the appearence of Lilypond engravings. Even though I enjoyed the process of writing music in Lilypond, the appearence of the score didn’t reach my goal of looking exactly like professional scores from the 20th century and my favorite examples of computer generated scores from the 21st century. I started micro-analyzing the scores that I enjoyed to see what it was that made them look natural.
Once I started to notice more differences between the scores I looked up to and the ones I was making with Lilypond, I started changing the engraving settings to align more closely with the style I had in mind, and I created my own stylesheet to easily import my tweaks in every score. Some of the most important changes are listed below, along with my reasoning for them.
Fonts
One of the first things I noticed was the rounded edges of some of the symbols, like the sharp sign. With this in mind, I decided to look at different notation fonts to use.
Eventually I decided on the cadence font. The glyphs have a lot of rounded edges similar to what I was looking for.
For the text font, I decided to use Liberation Serif, a new font based on Times New Roman that is available in LibreOffice. To my eyes it looks better than Times New Roman or the default lilypond serif font “C059”, looking more similar to the text I would find in 20th century scores.
Beams
\context {
\Voice
\override Stem.french-beaming = ##t
\override Beam.beam-thickness = #0.6
\override Beam.length-fraction = #1.0
\override Beam.damping = #4
\override Beam.breakable = ##t
}
One of the other differences I found between other scores and my own was how the beams look. Many times, especially in older scores, the beams were engraved in such a way that they are very thick and close together. I tweaked the settings to try to replicate this behavior. With these, combined with adding more “damping” (so the beams are more close to horizontal) and “french beaming” (in which the stem is not drawn in-between the beams), I’m very happy with how beams look now.
\context {
% This beam whiteout stencil is written by Jean Abou Samra
% Temporary solution to whiteout stave lines inbetween beams
% To avoid collision
\Score
\override Beam.stencil =
#(grob-transformer
'stencil
(lambda (grob orig)
(define (sanitize lst)
(filter (match-lambda ((x . y) (and (finite? x) (finite? y))))
lst))
(match-let* (((down . up) (ly:skylines-for-stencil orig X))
(down-points (sanitize (ly:skyline->points down X)))
(up-points (sanitize (ly:skyline->points up X))))
(ly:stencil-add
(stencil-with-color
(ly:round-polygon
(append-reverse down-points up-points)
0.0)
"white")
orig))))
\override Stem.layer = 10
}
Later on, I added this code snippet so that Lilypond would whiteout the space in-between the beams. This is so that if the beam is angled in such a way that a staff line should be visible in-between, it is hidden from view. This is a temporary solution until the way beams are calculated is changed so that the space between beams do not cross staff lines (a behavior which can be seen in some editions).
Flags
\context {
\Voice
\override Flag.stencil = #(straight-flag 0.6 0.75 0 1.5 0 1.5) % Thank you to Jean Abou Samra from lilypond users mailing list
}
One thing that I decided to change on my own (instead of getting inspiration from other scores) was to make the flags on an unbeamed note look the same as the beams on other notes. My reasoning for this is that it is easier to see (notwithstanding our previous experience reading regular-style flags), especially for editions of organ pieces in tablature notation which have more unbeamed notes. Unfortunately it wasn’t easy to make the flags look the same, it took trial and error to make them look identical in thickness and spacing.
Slurs and ties
\context {
\Voice
\override Accidental.hide-tied-accidental-after-break = ##t
\override Slur.thickness = #2
\override Tie.thickness = #2
\override Tie.springs-and-rods = #ly:spanner::set-spacing-rods
\override Tie.minimum-length = #4
\override Tie.minimum-length-after-break = #4
}
One problem that I encountered was that a tie would not be long enough when it appears after a line break. Not only is it hard to see, but crucial information (such as if it is dotted) can not be deciphered. I figured out how to fix this using the new #ly:spanner::set-spacing-rods
engraver. Another thing which helped was disabling the Lilypond practice of showing an accidental after a line break (this accidental would cause ties to move to weird place, even resulting in incorrect notation due to ties being placed directly on top of each other).
Glissando
\context {
\Voice
\override Glissando.thickness = 4
\override Glissando.breakable = ##t
\override Glissando.after-line-breaking = ##t
\override Glissando.minimum-length = #5
\override Glissando.minimum-length-after-break = #4
\override Glissando.springs-and-rods = #ly:spanner::set-spacing-rods
}
I had two big goals when changing the behavior of glissandos: to make straight lines connecting notes look better for my editions of early organ music and for a new notation I was experimenting with to show note length.
This alternate notation would take the place of notes tied together accross measures. I was mainly experimenting with this a few years ago. Now I would most likely just use ties like normal. However, I now know that there is another duration engraver built into Lilypond, which I will use instead.
Other
Besides these, I made a few small changes as well in the stylesheet:
- The parentheses are now brackets instead of round parentheses. These are useful for editorial additions.
- The spacing rules got changed to be just about as cramped as possible. Lilypond does a great job of adding space between staves and systems when needed, so I don’t need to worry about too little space.
- I made the figured bass larger, with font size 1.8.
- Originally, I changed the default paper size to Architect A (9x12in). However, nowadays I import a different file which changes the paper size to letter (8.5x11in) and reduces the margins around the score.
With all of these changes, I am really happy with how Lilypond engravings look. After years of minor tweaks I think that I have made good progress on accomplishing my goal of replicating how professional engravings look with this free program.
Conclusion
I am looking forward to sharing my adventures using this amazing piece of software with you! Also, I am planning to accept submissions from my friends at Oberlin and other students about their own experiences (the submission form for this will be available soon).