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
\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:
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:
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:
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:
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 🙂