Engraving Challenges: Modifying Already Beautified Scores

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

In his recent posts Janek shared with us his struggles with several Engraving Challenges that made him ask for more or less significant improvements in LilyPond (and in one case he actually implemented the needed improvement himself, as he’ll show you soon). So I think it’s time for a real success story in between (appropriate for our 50th (!) post). This will round off the first part of our series which was originally estimated to have three posts in total…

But I will start off by confessing to a mistake. Our intention was to finish the musical text, do the beautification after that, and do a last proof-reading run while approving Janek’s work. But it turned out that we had to apply nearly 200 fixes to the musical text on the 94 pages of the edition after the beautification was considered finished. So it clearly seems we let Janek prematurely beautify the scores.
The necessary fixes ranged from capitalization in lyrics or titles (completely harmless) over fixes in pitch and adding/removing/parenthesizing accidentals (potentially dangerous) to one extreme case of a slur which spans three measures and was accidentally hidden (asking for disaster).

Anybody who has ever prepared publication quality scores can easily see the awful mess this could have created. But LilyPond saved our day by really graciously accomodating these post-beautification fixes!
Thanks to the use of versioning the whole process of beautification and proof-reading is meticulously documented, so I can give you a quite specific report on how LilyPond coped with the task.


One nice thing about managing an edition project with LilyPond and version control is that I (as the editor) can directly apply any fixes to the shared source files without worrying about file conflicts. I don’t have to choose between sending Janek (the engraver) a list with fixes (letting him do all the work and requiring me to proof-read again afterwards) or asking him to send me a copy of the score file (which would be asking for trouble if he would ever think of editing it himself in the meantime). So I applied all the fixes found while proof-reading myself, committing them to the repository one by one. This gave me the opportunity to judge their implications individually and pass my comments along with them. But to my (pleasant) surprise the phrase I used in the vast majority of commit messages was “No side-effects noticed” – if there were any changes in layout, they were usually not for the worse.

In a typical run-through for a single song I applied five to ten fixes to the musical text and wrote a list of four or five “beautification requests”. These were rare cases where an issue may have escaped Janek’s eye or the even more rare ones where I was even more picky than he is ;-).
When Janek was assigned to finish off the song he would first process the beautification requests and then look for the issues created by my modifications. Usually I found only one or two commits post-processing my modifications, and actually there even were numerous songs he didn’t have to touch at all. Considering how delicate it is for an engraving software to accomodate subsequent changes I can’t say anything else than this was a success story for LilyPond’s performance.

Examples

In the remaining part of this post I will show you some examples of changes in the musical text and their impact on the layout. There will be some with and some without side-effects. Note that I didn’t collect these examples along the way – I have created them now, thanks to the fact that version control lets me inspect any past state of the project ;-).

03-4-poet-before
Fixing the poet's name obviously doesn't have any negative impact on the layout. So this is just an initial example ...

I wouldn’t have expected fixing the poet’s name to have any negative impact, so this is just an initial example.


03-3-parenthesize-before
Parenthesizing an accidental in the vocal line slightly changed the horizontal spacing, but didn't break anything.

Parenthesizing an accidental in the third beat of the left hand slightly changed the horizontal spacing, but was accomodated gracefully.


07-5-beam-slur-before
Changing the beaming and a slur is already an involved change - but again LilyPond managed to do without needing further tweaks.

Changing the beaming and a slur is already an involved change – actually I’d have expected this to break the line’s layout. But again LilyPond managed to do without requiring further tweaks: the staves were automatically moved to accommodate upward stems.


07-6-voicing-before
Restoring the voicing of the original edition. There is enough space available, but mungling with the voice distribution could be dangerous - not for LilyPond

Restoring the voicing to that of the original edition. Although there is enough space available mungling with the voice distribution could be dangerous – but not for LilyPond.


07-7-remove-accidental-before
Removing the accidental. This did cause a regression: The tie on the fis'' is now too short because the natural is missing.

Removing the natural before the c'' actually did cause a regression: The tie on the fis” is now too short (previously LilyPond used more horizontal space here because of the accidental).


07-3-reattach-slur-before
Reattach. the right and of the long phrasing slur. The slur had to be reshaped but nothing else was broken.

The right end of the lower phrasing slur was attached to the wrong note. Of course reattaching it caused a regression (as this clearly is a kind of slur that you couldn’t seriously expect to be handled perfectly by a computer program) – but notice that everything else is still working and nothing was broken.


And finally the example that surprised me most. While proof-reading I noticed that there was a long phrasing slur missing that should span nearly the whole system, from the g' in measure 27 to the last fis'' in measure 30:

07-5-long-slur-before

I was sure adding this would severely damage the layout of that system. But please see now how gracefully LilyPond managed to insert that slur: slightly increasing the distance between the staves to prevent the new slur to collide with the crescendo hairpin, but completely without any negative side-effects. This is really near the automatic engraving we’re after 🙂 !

Making a very long phrasing slur appear without any negative side-effects.

2 thoughts on “Engraving Challenges: Modifying Already Beautified Scores

  1. Vaughan

    Every moment spent beautifying a score where the text is not settled is potentially a moment wasted. It’s the same in my day job as a sound engineer—edit together a performance the musician is happy with, and only then apply mixing tweaks. Further editing gets more difficult and prone to unpredictable side effects.

    Lilypond’s vertical spacing and collision avoidance is one of its best features. It’s far ahead of Finale and brilliant for choral music (altos, I’m looking at you!).

    Reply
    1. Urs Liska

      Yes, LilyPond’s quality shouldn’t be an excuse for sloppy project management ;-).
      But it was a good experience to see haw far it could help us getting over this problem.

      Reply

Leave a Reply

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