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
Those of you who are also reading the lilypond-user mailing list may have noticed from my recent activity that I’ve been dealing with a certain score lately. Actually this is an edition that is right now being printed, and while it is far from being as exciting a project as some other edition projects discussed before on Scores of Beauty I think it’ still a nice one. And I hope it’s acceptable to use this platform for a shameless plug, especially as I will (of course) spice it up with some serious LilyPond discussion.
Today’s post starts a set of two articles that is a little bit of everything: it’s admittedly an advertisment but also a report about LilyPond’s strengths and weaknesses, and it gives insights in some useful techniques. Continue reading
Recently we have discussed LilyPond’s capabilities for engraving contemporary music. It seems many composers consider extended notation with the computer a daunting task and prefer using graphical approaches for it, like drawing tools in graphical programs or even post-processing scores in graphics programs like Inkscape or Illustrator. However, while this may seem straightforward, I’ve always felt it’s conceptually inferior, mostly because this approach is a one-way street: once you have edited the resulting PDF in a drawing program you can’t ever go back to editing the content of the score. LilyPond gives you the option of encoding what you mean, and while it is admittedly a complex task to create extended notation with it, I definitely think this feature alone makes it worth the trouble. Of course you have to consider that a composer doesn’t necessarily have to do the programming himself, there will usually be generous help from the community. And developing a library specifically addressing contemporary notation needs will (hopefully) be an extremely powerful asset for the LilyPond toolkit.
Some time ago Matteo Ceccarello appeared on the LilyPond stage and announced a new library that merged several ideas from this blog. My own posts about a grid approach and two posts by Jan-Peter Voigt had inspired him to develop a library where the “cells” of the grid can be directly stored in a tree-like Scheme object. I helped him integrating this library in openLilyLib where it now lives as GridLY. This process and collaboration produced some significant by-products, for example an automated testing infrastructure for openLilyLib. And now Matteo presented a new tool that opens up some important perspectives for openLilyLib. Continue reading