Engraving Challenges: Structuring the Input

This post is part of a series analyzing LilyPond’s performance during the preparation of a new edition of Oskar Fried’s songs.

With complex piano music, like Oskar Fried wrote, it is fundamental to enter the musical content in the correct, logical structure. It is essential to assign the notes to correct voices and make use of \voiceOne, \voiceTwo etc. Otherwise you won’t be able to make sense of LilyPond’s layout decisions, nor know how to tell LilyPond to do what you want.

I had only entered two or three songs (there had been a few songs entered earlier by others, and the majority of the music was copied from the original editions by Urs), but I remember one interesting thing: I used crayons to mark voices. This may sound silly – in fact, I felt as if I were back in kindergarten – but with piano music this is really helpful: after all, voices may jump into existence and disappear all the time, move between staves, etc. There are usually 2 “main” voices on each staff, but occasionally this number can go up to 4. Even if you have experience, there are situations where only after analyzing a long fragment of the score you can be sure how to assign voices (because they jump around so much, and spawn new “temporary subvoices” so often), and in such situations crayons are your best friends. Just take a look at the following examples to see how complicated this music can be in terms of voicing:

Excerpt from op. 7, 2

Excerpt from op. 7 no. 2

excerpt from op. 8-1

excerpt from op. 8 no. 1

It is important to get voicing right when entering the musical content, because correcting wrong voicing takes a long time. (Urs also told me that in some cases entering the scores from scratch would have taken him about the same time as fixing voicing issues in input files entered by others.) When dealing with cross-staff or cross-voice notation, I occasionally encountered issues caused by wrong voicing, and fixing them usually required reading the code 5 times to understand how the voices were laid out, and then rewriting that fragment so that the notes were placed in appropriate voices without breaking other things. Here’s one such case:

problem with cross-staff stem

problem with cross-staff stem

Unfortunately, I don’t have the source code that produced this output (as this was before we started using version control – but that’s a topic for a post on its own), so I cannot exactly say what was wrong in it, but I remember that I was unsucessfully trying to move the notes at the end of the measure (colored in magenta and blue) for a long time before I finally decided to rewrite the code – and when I did this, I got the desired note arrangement almost right away:

that's how it should look like.

that’s how it looks after fixing voices and general beautification.

Of course it would have been very quick and rather painless to “fix” such an issue with a graphical program where I could simply have dragged the notes to a visually satisfying position. But then the logical connection between content and visual representation would have been lost – which would fall on one’s toes very hard as soon as you have to modify anything in the layout.
Fixing voicing thoroughly guaranteed that the logical structure will be intact even after major modifications like changing page layout and line breaking.

Appropriate logical structure is especially important when dealing with complicated tie and slur notation. In LilyPond, ties and slurs can connect only notes that are in the same voice, so when the composer uses a cross-voice tie one has to create artificial voices that will allow you to “fake” the desired tie. These artificial voices must fit in the logical structure of the piece, or weird things will happen. Here is another case where changing voice structure was necessary to get the desired notation:

problems with cross-voice ties

badly structured cross-voice tie (highlighted in blue) caused the collision of half-note chord with the upstem quarter-note.

here's the notation that we wanted to produce.

here’s the notation that we wanted to produce.

Quite frankly, I think that having to define such artificial voices is inconvenient and LilyPond should have a simpler way of specifying cross-voice ties. I imagine that it should be possible to design a CrossVoiceTie object that could be used in the code just like an ordinary tie. In fact, it is already possible to move the Tie_engraver from the Voice context to the Staff context – when you do this, ties can connect notes from different voices. Unfortunately this solution has some downsides that usually prevent you from using it effectively.

The conclusion of this post is: think ahead and take care to define appropriate logical structure for the music you are engraving, or you may run into situations that are tricky to solve. If you encounter puzzling problems and wonder why things get so complicated, it may mean that the structure you had used for the music is wrong. But when you get it right – and with some practice it’s quite easy to get it right – you will be rewarded with a result that is more stable and reliable than the “hacks” you’d have to use with graphical notation programs.

In the upcoming posts I will show you a few areas where I really had to wrestle with some LilyPond peculiarities – expect an unsparing analysis of LilyPond performance, with no sugarcoating, but please don’t get discouraged after reading it! Despite these weaknesses I still prefer LilyPond to other tools; and most importantly, the issues I point out can be solved 🙂

4 thoughts on “Engraving Challenges: Structuring the Input

  1. Pingback: Engraving Challenges: Slurs and Ties | Scores of Beauty

  2. Noeck

    Thanks for that post – and the other engraving challenges posts! They are really interesting.
    Concerning the last image: Isn’t it always the case that the two tied notes logically belong to the same voice? From the (short) section in the image, it looks like this voice joins the chord below. So the voice of the two fs is the same but the representation for the half note f adjusts to the other voices that it joined (stems down). Perhaps, there are better examples for your case, but to me it looks like the missing feature is a possibility to join voices (perhaps not even missing?) and not the possibility to tie notes from different voices. Am I mistaken?

    1. Urs Liska

      The problem with piano music is that it can simply ignore correct voicing structures. A pianist (composer) may decide to tie any note to anything. In the case of this example you could argue that the chord isn’t a chord but rather a stack of voices. But that doesn’t match compositional practice. As said pianists tie anything to anything, voices to chords or voices to other voices, and while this may be considered orthographically dubious it’s just what composers do all the time. Therefore LilyPond should have an easier way to do so.

      Another common case for this problem is with slurs that span a somewhat larger section of music. While in LilyPond you have to scrupulously ensure beginning and ending note are in the same voice context this really should be made simpler.

  3. Noeck

    I see. It is a bit against my personal wish for logical structure, but I think I have to agree and accept that this is common practice in compositions.


Leave a Reply

Your email address will not be published. Required fields are marked *