The current stable version of LilyPond (2.18.2) has a pretty annoying limitation for tablature users. If you change the TabStaff font to something different from the default (Feta) and your score contains dead notes, you won’t see any symbol on the TabStaff, because the font you chose probably does not have a cross glyph. So, at least in these scores, you are forced to use Feta (a serif font) also for tablature. This implies that you may not be able to write a tablature book in sans serif font or you’ll have to sacrifice consistency. This was the case for a project of mine, where all the pieces without dead notes used a sans serif font, but I had to use serif in those pieces where dead notes were present. Fortunately this has been fixed in development version 2.19.55, released this week. Now my book project will have consistent font settings! Let’s see a simple example.
I have regularly described the advantages of working with LilyPond and version control on this blog (for example in an ironic piece on things one would “miss” most with version control), but this has always been from the perspective of not having to use tools like Finale or MS Word. Now I have been hit by such a traditional workflow and feel the urge to comment on it from that perspective … Continue reading
Oops, I have to plead guilty for some vanity-Googling my name in combination with “LilyPond”. OK, this is embarassing, but on the bright side it revealed some blog posts I didn’t know yet. And there’s one in particular that I want to recommend today because it’s a post that actually should have appeared here a long time ago (and my mention is actually very minor). Joshua Nichols wrote a very interesting piece on software freedom, which I suggest to read here: https://joshdnichols.com/2015/11/16/why-i-love-lilypond-freedom/
Recently a concern with distributed editing concepts has been brought to my attention. As this adds to other existing reservations I have already been aware of and as I’ll coincidentally be talking about exactly that matter at a “Winterschool” conference in a few weeks this is an opportunity for a post about responsibilities in distributed edition workflows. I am convinced that any reservations about compromising quality of musical editions by giving up established workflows or by incorporating the work of multiple contributors are completely unfounded, or rather solely based on fear of the unknown and fear of change. In fact distributed work with text based tools and version control gives lots of flexibility and exciting new possibilities and adds multiple layers of safety nets rather than adding risks. Continue reading
This summer, I’ve had the special opportunity to participate in the Google Summer of Code (GSoC) program with Lilypond. To describe GSoC briefly, students worldwide are paid a stipend by Google to work on coding projects for various open source organizations. My project deals with spanners, musical objects that start and end in different places, like slurs and crescendi. Specifically, I’ve been working on allowing users to create cross-voice spanners—spanners that start and end in different voices.
About a year a go I posted a report of my first appearance at the Music Encoding Conference that had taken place in Florence (Italy). I then introduced the idea of interfacing LilyPond with MEI, the de facto standard in (academic) digital music edition and was very grateful to be welcomed warmly by that scholarly community. Over the past year this idea became increasingly concrete, and so I’m glad that German research funds made it possible to present another paper at this year’s conference although Montréal (Canada) isn’t exactly around the corner. In a set of two posts I will talk about my my impressions in general (current post) and my paper and other LilyPond-related aspects (next post). Continue reading
A brief overview of digital music font design
Unlike designers of (digital) text fonts, music font designers historically were not restricted by standards and had great freedom, which has been both a blessing and a curse. While there was some common sense about what the kernel of music symbols should be (clefs, noteheads, accidentals, etc.), the actual position of characters in the font, their naming (though there was generally none provided), and the addition of rarer symbols beyond the basic set was left up to the designer’s imagination and to some specific requirements of the target music notation software.
Things are changing drastically with SMuFL, a font standardisation effort initiated by Daniel Spreadbury from Steinberg and now hosted at W3C in a welcome “joint venture” with MusicXML. This addresses issues of symbol position, naming and repertoire in a universal way, the idea being a world where fonts can be used in different scoring applications – just as everybody expects text fonts to be usable in any text processor or layout program. SMuFL is a great source of inspiration for the designer – surely one of its benefits – but it also imposes new constraints and requirements, and leads to a more demanding design workflow. Continue reading
Last week I wrote about a new edition of Saint-Saëns’ famous “Swan” for which I prepared a new piano arrangement. In the closing of the article I showed the exception to the rule, namely an issue where LilyPond did not serve me well right from the start, with this example of particularly ugly horizontal spacing:
Of course there is a piano part in addition to that cello line, but nevertheless it seemed more than strange that LilyPond should be doing that badly, and I had to find a solution (and more urgently, a cause) for the issue. As it turned out, my spacing issue is an ugly side-effect of a major LilyPond strength: optical spacing. Today I will show you in some detail what this is about – and why it is a limitation in this special case. Continue reading