In the previous post I wrote about the necessity to carefully organize the voicing structure in LilyPond input files in order not to run into difficult and baffling situations.
Today I’m going to confront you with the most common, and at the same time quite demanding, task from this project: beautifying slurs and ties.
Slurs and ties are probably the notational elements that most often need adjustments (I’ll give you detailed statistics later; for now just take my word that I had to correct a lot of slurs and ties in the Fried project).
This is probably because it’s hard to teach a computer how to draw a “good-looking” curve. There are complicated situations where you couldn’t seriously expect a computer to make the right decisions by itself (e.g. for slurs that cross staves), but there are also lots of situations where LilyPond simply didn’t manage to get a satisfying solution automatically.
Now, the problem with adjusting slurs is that it’s awkward to do this using a text interface. It’s inconvenient enough when you have to specify numerical offsets to move an object around (for example, a dynamic) – but how can you alter the shape of a curve using just your keyboard? In graphical notation packages all you have to do is to click and drag slur’s control-points with a mouse (slurs are usually implemented as Bézier curves) – that’s easy, fast and intuitive. Unfortunately, with LilyPond you have to adjust the coordinates of the control-points. This is not user-friendly (especially because you don’t see how the adjusted slur will look like until you recompile the score), and I daresay that this is the biggest inconvenience of LilyPond compared to graphical notation software.
Text input offers some great and unique advantages – as we’ve pointed out more than once, processing and storing musical content and tweaks in textual form is surely superior to other formats (see for example Urs’s fundamental text about plain text workflows).
But lacking a graphical user interface to this plainly sucks.
Fortunately there are plans to add graphical editing capabilities (without compromising text based processing) to Frescobaldi. If that will become reality, working with LilyPond slurs will become more efficient by magnitudes!
Anyway, the situation wouldn’t be a real problem if ugly slurs appeared only from time to time, but with complex music this is not the case. I’ll give you some examples of unsatisfactory default slurs so that you’ll get the idea of the work that was necessary.
Back when I was just beginning to work on the project, broken slurs in particular looked very bad:
Fortunately, the situation has been dramatically improved by Keith OHara in June 2012, when he fixed issue 379. Nevertheless, broken slurs still frequently needed adjustments; usually the slope of one (or both) part of the slur was unsatisfactory:
Sometimes slurs interfered with phrasing slurs (this was easy to fix):
…and there were other problematic slurs – for example these:
As you can see, there was a lof of work… Fortunately, I had a tool that made this a lot easier: long time ago, on a computer far, far away 😉 David Nalesnik wrote a function called
\shapeSlur (view in the LilyPond Snippet Repository), which allows to adjust slurs and ties relative to their default appearance.
I have used this function all the time and it was a lifesaver – in fact, our need triggered David to update and improve it (see this discussion on the lilypond-user mailing list), and since LilyPond 2.16
\shape is now part of the official distribution (read more in the documentation)!
I’ll tell you more about
\shape later (it has been recently improved again, and it’s now even more powerful!), and I’ll also provide detailed statistics and timing information – for now, we shall move on to horizontal and vertical spacing.