Using special characters from SMuFL fonts

Recently Joram Berger gave an introduction to Steinberg’s proposed new font standard, Standard Music Font Layout SMuFL and its possible use in LilyPond. He also compared LilyPond’s Feta font and Bravura, the only SMuFL font that is currently available. In addition I would like to expand on some specific cases where accessing specific SMuFL glyphs can become handy in solving specific notational problems. But I promise to put in some useful tips also for the LilyPond user more interested in solutions using the regular Feta font.

Bravura glyphs in a Feta context

In the music example in the mentioned post SMuFL Fonts in LilyPond there’s a niente symbol present in the Bravura part but not in the default Feta part. (This is mentioned in the comments but not in the text.) This could be good news for the engraver who needs a niente glyph and is willing to otherwise accept the appearance of the output with Bravura font. But as Joram mentions in the text: “There are still open issues with the integration of SMuFL with LilyPond, therefore the use of Bravura in LilyPond cannot be recommended for publication quality scores, yet.”

In the case of the niente symbol the problem is admittingly not huge; the symbol can quite easily be produced with an italic ‘n’ with markup. But there are other glyphs that are not so easily to achieve. In the comparison between Feta and Bravura Joram lists examples of glyphs that are present in Bravura but not in Feta. While there always seem to be a way to accomplish things natively in LilyPond, especially if you’re a competent Scheme programmer, I think it’s nice to know that almost any music-related glyph can be accessed directly in the Bravura library.

But if it’s not an alternative yet to use the Bravura font in LilyPond, why would it help if a glyph is present in that font? While it’s not recommended to use the Bravura font as an complete replacement to Feta, the main obstacle against using individual glyphs from Bravura in a Feta context is that they may not look completely compatible. Setting the problem of compability aside I think this is an interesting technique and I’ll give you some samples of it in this post.

Simple Markup

I’ll come back to some of the notational elements in Jorams list in a moment, but first I would like to discuss an example which was discussed on the LilyPond users mailing list. Urs requested a symbol which in the Bravura font map is called “Unstress” ( ˘ ), and can be compared to the sign that denotes light syllables in a poem. This then is an unusual kind of articulation not easily achieved with the Feta font but accessible in Bravura. The key how to access it is in Jorams post; he mentions two useful commands \smuflglyph and \smuflchar. With the first you use the name of the glyph and with the second you use the hexadecimal number. These commands can be put in a markup context. Here is the example with the ‘unstress’ glyph: (The include call assumes the presence of a path to the snippets repository, and will be omitted for the rest of the post.)

\include "custom-music-fonts/smufl/definitions.ily" 

\relative c'{
  \stemUp
  f4 _\markup { \smuflchar #  #xE486 } % Unstress below
  r4
  \stemDown
  f'4 ^\markup { \smuflchar ##xE485 } % Unstress above
  r4
}

unstress
In a similar way you can use any SMuFL character in a markup. This example already shows the pros and cons of the approach: It is easy to use any glyph from the comprehensive SMuFL standard this way, but the glyphs in this example don’t really go well together with the Feta articulations style. But at least you do have them available.

An alternative without using SMuFL is to look in an utf-8/unicode character table and see if you can find what you’re looking for. Then you can use the regular \char command or just paste the character directly (provided the font actually contains the respective glyphs). I found for example this ‘˘’ unstress symbol. Read more about using special characters in LilyPond’s documentation.

Changing tremolo glyph

To use SMuFL glyphs in a markup was pretty straightforward I think. Now for something more difficult. A while back I engraved a score with a tremolo symbol that’s not in the usual LilyPond repertoire. It looks like a ‘z’ across the stem, and I’ve learned that it’s called a Penderecki tremolo after the composer Krzysztof Penderecki. (You may know it as a buzz roll, but in the SMuFL library they’re actually two different glyphs.)

As this symbol is in the extensive SMuFL library my idea was to use this to achieve the requested notation. In the SMuFL library there are two glyphs, one that is just the ‘z’ and one that includes the whole stem (with the ‘z’). My initial idea was to change the whole stem. But in fact that’s unnecessary; it’s better to only change the tremolo symbol. The proper solution was given by Nathan Ho, and reads like this:

#(define (penderecki-tremolo grob) 
   (grob-interpret-markup grob 
     (markup #:vcenter #:smuflglyph "pendereckiTremolo"))) 

\new Staff { 
  \override StemTremolo.stencil = #penderecki-tremolo 
  c'4:32 d'4:32 e'4:32 f'4:32 
  c''4:32 d''4:32 e''4:32 f''4:32 
}

flz-with-z
Again as an alternative could you not just use a ‘z’ instead of the SMuFL glyph? It would be something like this :

#(define (z-tremolo grob) 
   (grob-interpret-markup grob 
     (markup #:vcenter #:halign CENTER #:bold "z"))) 

\new Staff { 
  \override StemTremolo.stencil = #z-tremolo 
  c'4:32 d'4:32 e'4:32 f'4:32 
  c''4:32 d''4:32 e''4:32 f''4:32 
}

z-tremolo
In my opinioin using an ordinary ‘z’ doesn’t look as good as the dedicated SMuFL glyph, although I’m sure there’s a better non-SMuFL solution. Please put any suggestions in the comments.

Clusters

One of the things that was mentioned in Joram’s (second) post was the possible use of SMuFL for producing cluster notation. I would like to show how this can be done in actual examples. First I will change the notehead into a cluster notehead. I use a very similar technique to the one from the previous example:

#(define (white-cluster grob)
   (grob-interpret-markup grob
     (markup #:vcenter #:smuflglyph "noteheadClusterSquareWhite")))

\new Staff {
  \override NoteHead.stencil = #white-cluster
  \time 4/2
  c''4 c''4 c''2 c''1 c''\breve
}

smufl-clustersI
The same technique can of course also be used to change the notehead to any other appropriate SMuFL glyph. Just change the glyph name, and by all means also the function name.

Next we want to have different note heads for the different note values. I then use an adaptation of the code for producing ordinary SMuFL noteheads in the snippets repository:

#(define (cluster-notehead grob)
   (let* ((log (ly:grob-property grob 'duration-log))
          (style (ly:grob-property grob 'style)))
     (grob-interpret-markup grob
       (cond
        ((<= log -1) (markup #:vcenter #:smuflglyph
                       "noteheadClusterDoubleWhole3rd"))
        ((<= log 0) (markup #:vcenter #:smuflglyph
                      "noteheadClusterWhole3rd"))
        ((<= log 1) (markup #:vcenter #:smuflglyph
                      "noteheadClusterHalf3rd"))
        (else  (markup #:vcenter #:smuflglyph
                 "noteheadClusterQuarter3rd"))))))

\new Staff {
  \override NoteHead.stencil = #cluster-notehead
  \time 4/2
  c''4 c''4 c''2 c''1 c''\breve
}

smufl-clustersII
But in the image from Joram’s post some of the clusters were covering more of the staff (and some the whole staff) – well, that’s the point of clusters, isn’t it, to be more flexible in their pitch range. But how can this be achieved? Remember the swirling vibrato spanner from the same post? These are both achieved by an additional feature of the SMuFL glyphs; they can be combined.

\markup {
  \override #'(baseline-skip . 0)
  \column {
    \smuflglyph #"noteheadClusterHalfTop"
    \smuflglyph #"noteheadClusterHalfMiddle"
    \smuflglyph #"noteheadClusterHalfMiddle"
    \smuflglyph #"noteheadClusterHalfBottom"
  }
}

smufl-clustersIII
But how on earth could I make use of this markup as an actual notehead? Not knowing exactly how to translate this to scheme readable code in a function the easiest trick is to turn to the old helper \displayMusic (which is a bit awkward when it contains no music but only markup). With its help I could determine that the necessary code is this:

#(define (big-cluster grob)
   (grob-interpret-markup grob
     (markup
      (#:override
       (cons (quote baseline-skip) 0)
       (#:column
        (#:smuflglyph
         "noteheadClusterHalfTop"
         #:smuflglyph
         "noteheadClusterHalfMiddle"
         #:smuflglyph
         "noteheadClusterHalfMiddle"
         #:smuflglyph
         "noteheadClusterHalfMiddle"
         #:smuflglyph
         "noteheadClusterHalfBottom"))))))

\new Staff {
  \override NoteHead.stencil = #big-cluster
  \time 4/2
  e''\breve
}

smufl-clustersIV
The next step beyond this is to let the user of the function decide the height of the cluster note head, i.e. how many of the middle glyphs to put in. I leave the solution for this open as a challenge for the reader (maybe it will show up in the comments). Of course it should reflect the actual range of the cluster so it should be possible to provide the top and bottom notes as arguments.

Would there be an alternative without resorting to SMuFL? Well, LilyPond is quite powerful when it comes to creating graphics in markup, so I’m sure it’s possible to achieve customized cluster noteheads and make them accessible through easy-to-use functions. I’ll give you a simple filled box as an example to end off:

#(define (boxfill-cluster grob)
   (grob-interpret-markup grob
     (markup
      (#:filled-box (cons 0 1.6) (cons -1 2) 0.3))))

\new Staff {
  \override NoteHead.stencil = #boxfill-cluster
  \time 4/4
  c''4 c''4
}

smufl-clustersV

Music Functions 4: Recursion

Today we’ll come to an end with a series of posts demonstrating how to write a comparably simple music function in LilyPond. I deliberately chose to describe the stuff with such verbosity and at that gentle pace because I think that’s what is missing in LilyPond’s (otherwise excellent) documentation. At least I think I would have greatly benefitted from that kind of explanation …

In the first part we started considering how to insert a Scheme music function in a LilyPond input file, and in the second part we started writing a function that colors an arbitrary function with an arbitrary color. While this was more or less hard-coded and exposed lots of redundant code we wanted to improve it in the third part through refactoring and list processing. Unfortunately this didn’t work out as easily as expected, and finally we’ll be solving the task through recursion today. Continue reading

Music functions 3: Reusing Code

In the last post We wrote a music function that took an arbitrary music expression and applied an arbitrary color to it. The problem we immediately saw is that we manually had to override all properties – and that we still didn’t manage to catch them all. In general terms, a function that redundantly calls \override for each new property isn’t exactly elegantly programmed. So today we will do better and at the same time learn something about reusing code by refactoring and by processing lists. Continue reading

Music Functions 2: Start Doing Something Useful

In the previous post I demonstrated how to include Scheme code in LilyPond input files, and we saw our first music function, although it still was a static function only producing a hard-coded middle c. Today we’ll do some more by writing functions that actually do something useful and can handle arguments. Continue reading

Music Functions 1. Getting to Grips with Scheme in LilyPond

With this post I intend to start a series of posts introducing writing Scheme music functions in LilyPond input files. Please note that this is not a guru’s wisdom poured into blog posts but rather a documentation of my own thorny learning process.

Being able to include Scheme code in LilyPond files is one of the foundations of Lily’s higher powers, as this isn’t “just some scripting interface” but allows you to interact with its processing on the lowest level. Basically LilyPond works through a combination of compiled C++ code and Scheme code interpreted at runtime. Injecting Scheme code in input files is therefore literally extending LilyPond’s built-in capabilities. Continue reading

One Day At the Messe

Travelling sixteen hours by bus and having a whole day of fun can actually make you tired.

Travelling sixteen hours by bus and having a whole day of fun can actually make you quite tired.

We had lots of fun at the Frankfurt Musikmesse :-) .
It has been a great experience for both of us, me having most of Thursday and Janek joining for Friday. Actually we were so excited that we forgot to make pictures during the Messe ;-) – sorry for that! Continue reading

Oskar Fried: the Big Bang

It seems the circle is going to close now.
Nearly three and a half years ago Janek introduced himself to the lilypond-user mailing list with this message – and see who were his first two contacts from the LilyPond community :-) .
In the meantime we had several projects, exchanged thousands of emails (not including on-list communication), even talked a few times over Skype – but never had the opportunity to see us in natura (and I think our Avatars aren’t exactly revealing). Now’s the time to change this: On Friday we’ll finally meet at the Musikmesse Frankfurt! Let’s hope the blind date won’t be a disappointment ;-) .

But this isn’t the Big Bang promised in this post’s title. ;)

The Big Bang is that…

… (drum roll) …

This Friday we’ll receive the BEST EDITION 2014 award of the German Music Publishers’ Association for our edition of Oskar Fried’s songs!! :) :) :)
BEST-EDITION-small Continue reading

Engraving statistics: timing

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

Hello again!

Our regular readers must have noticed that our “blogging schedule” is recently quite spotty – we apologize for that! There’s a lot of things that are keeping us busy, and one of them is very important news for LilyPond – we’re going to announce it this Tuesday, be sure to drop by! :)

Anyway, I’ve recalled that I had written one more post draft about our Fried project, and I’ve decided to finish it because this information may be interesting for you: it’s the concluding statistic – the timing of my work. Continue reading

Massive improvement in LilyPond’s horizontal spacing!

In the post about horizontal spacing in Fried Songs edition I have complained about a nasty bug in LilyPond horizontal spacing (issue 3304), which was causing us a lot of trouble in pieces that contained a lot of triplets. I am extremely happy to announce that the bug has been fixed by Keith OHara!
Continue reading

Feta and Bravura

In the last post I have shown what the SMuFL font layout is and how it can be used in LilyPond. In this post, we will have a closer look at the SMuFL compliant Bravura font and compare it to Feta, which is the default music font in LilyPond. Let’s look at the example from the snippets repository again: Continue reading