Author Archives: smufl

Update from the new W3C Music Notation Community Group

The co-chairs of the W3C Music Notation Community Group, the new home for the development of SMuFL and MusicXML, have together published an outline of the short- and medium-term goals of the CG’s work, including a call for responses from the community members. You can read that outline here.

If you have not yet joined the W3C Music Notation Community Group, you are strongly encouraged to do so. Information on joining the group can be found here.

SMuFL development moves to new W3C Music Notation Community Group

Steinberg is excited to be a founding member of the new W3C Music Notation Community Group that has been established with the support of the World Wide Web Consortium (W3C).

The Community Group will develop and maintain specifications for format and language of notated music as used by web, desktop and mobile applications. The initial task is to maintain and update the MusicXML and SMuFL specifications. The goals are to evolve these specifications to handle new use cases and technologies, including greater use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications.

Over the past 15 years, MusicXML has become the standard format for the interchange of music notation data between applications, and is now supported by more than 200 applications across desktop and mobile operating systems, and on the web. Since its 2011 acquisition of Recordare, LLC, MakeMusic has been responsible for the development of the MusicXML standard, under the stewardship of MusicXML’s original creator, Michael Good.

SMuFL is rapidly becoming the standard for digital fonts containing symbols used in conventional Western music notation, and both describes a repertoire of more than 2,400 recommended symbols and sets out guidelines for font makers and software developers to ensure symbols are rendered correctly within applications. Since its introduction by Steinberg in 2013, SMuFL has already been implemented by applications across desktop and mobile operating systems, and on the web, and will also be supported both in Steinberg’s in-development scoring application and an upcoming version of Finale from MakeMusic.

Together, MusicXML and SMuFL represent core technologies that can foster the further development of applications for music notation across a broad range of platforms. By moving future development of MusicXML and SMuFL into the new W3C Music Notation Community Group, MakeMusic and Steinberg are signalling their intent that these standards will continue to be open, free to use and developed according to the needs of the wider world of music.

From left to right: Joe Berkovitz; Michael Good; Daniel Spreadbury.

From left to right: Joe Berkovitz; Michael Good; Daniel Spreadbury.

The new Community Group is co-chaired by Michael Good, the inventor of MusicXML and VP of Research and Development at MakeMusic, Daniel Spreadbury, the inventor of SMuFL and Product Marketing Manager for Steinberg’s in-development scoring application, and Joe Berkovitz, President of Noteflight and co-chair of the W3C Audio Working Group.

You can read press releases from the three companies represented by the three co-chairs of the Community Group here:

How to get involved

The plan is for SMuFL development to move to the new W3C Music Notation Community Group with immediate effect. If you are currently a subscriber to either of the SMuFL-related mailing lists, you are strongly encouraged to join the Community Group as soon as possible. There are no fees associated with joining a Community Group, so it is free for everybody who wants to get involved to become a part of the process. You will need to agree to the terms of the standard W3C Contributor License Agreement as part of the process of joining the Community Group, to give consent for your contributions to the SMuFL and MusicXML specifications to become part of the final report produced by the Community Group.

Any questions?

If you have any questions about these changes, please post them to the SMuFL discussion list, or contact Daniel Spreadbury at Steinberg directly.

SMuFL 1.18 and Bravura 1.18 released

We are pleased to announce the release of SMuFL 1.18, a minor update to the specification that is focused on enriching the specification of font-specific metadata, as well as adding a small number of new characters to the standard.

Standard file system locations for font-specific metadata files are now defined in the specification. This is intended to solve a number of issues: firstly, to provide applications that want to consume SMuFL fonts with a reasonable way of determining whether or not a given font is SMuFL-compliant, via the presence of the metadata file; and secondly, to provide font designers with a standard location for these files to be installed, and updated along with new versions of the font.

Very simple installation scripts (based on Inno Setup for Windows, and Packages for Mac) are provided on GitHub for font developers to use as the basis of creating their own installers, and specify the appropriate locations for the font-specific metadata files to be installed.

The specification of the font-specific metadata file itself has also been enriched, with a new optionalGlyphs structure that should list all of the optional glyphs (i.e. those outside of the core, recommended glyphs, located in the range U+F400–U+FFFF) by name, code point, and (optionally) class. Steinberg’s in-development scoring application uses this structure as the canonical source of information about the optional glyphs present in a SMuFL-compliant font. Additionally, entries for glyphs in the sets structure should now contain the field alternateFor, which specifies the name of the core SMuFL glyph for which this glyph is an alternate.

Work is currently in progress on tools to help font developers ensure that their font-specific metadata files are well-formed: firstly, the use of a JSON Schema that will allow a variety of editing environments and tools to validate the syntax of a given metadata file; and secondly, a script that will check a syntactically-valid metadata file for common problems, such as misnamed glyphs, missing structures, and so on. When these tools are in a more complete state, a further announcement will be made.

Additions to the repertoire of recommended characters in this version include a new Metronome marks range, intended to disambiguate the (previous) dual purpose of the Individual notes range, making it clear which range should be used in text-based applications or text contexts within scoring applications for drawing notes in runs of text versus notes on a stave.

Four of the glyphs in the Clefs range, the triangular clefs between U+E06F and U+E072, have been renamed. This represents the first changes to canonical glyph names since version 1.0, and should be considered an exceptional circumstance based on the discovery of significant semantic errors in the description of the existing characters. Detailed information on this change can be found in this post to the SMuFL discussion list.

As always, full details of all of the changes since January’s SMuFL 1.12 release can be found in the version history, and you can also download the updated SMuFL 1.18 specification.

The Bravura font family has also been updated to version 1.18, and implements all of the changes in SMuFL 1.18, with the exception of the new recommendation that time signature digits should include side bearings to aid in character spacing for time signatures with multiple digits in the numerator and/or denominator. (It is expected that this recommendation will be followed in a future version of the font.)

There have been a number of minor revisions to Bravura since version 1.12 was released in January, including improvements to the appearance of key glyphs (thanks to Tucker Meyers for once again providing cleaner outlines for some ranges, including dynamics, ornaments, and keyboard techniques), fixes to the font-specific metadata file, and more. Complete details of the changes are found in the FONTLOG on GitHub.

You can download the updated Bravura family, including OTF, EOT, WOFF, and SVG versions of both Bravura and Bravura Text, from this web site, or browse the repository at GitHub.

Development of SMuFL will continue, as dictated by the needs of its community, and I encourage you to get involved in the ongoing discussion. If you are using SMuFL or Bravura for your project, I’d love to hear about it, so please get in touch to let me know what you’re working on.

SMuFL web service now available from Edirom

Peter Stadler has announced the availability of a simple web service, intended primarily for use with people working with the Text Encoding Initiative (TEI) format, to serve up the appropriate TEI-encoded XML entities for including SMuFL characters in TEI documents. The web service can also serve up JSON and JSONP versions of these entities, as well as graphical representations of each glyph in PNG format.

You can read about how to work with the web service here, or browse the repository of glyphs here.

New SMuFL-compliant font November 2.0 now available

M4

Composer, pianist, software developer and font designer Robert Piéchaud has today launched a major update to his widely-admired music font, November, which adds hundreds of new symbols, and compliance with SMuFL. November 2.0 is the first commercially-licensed font to include SMuFL compliance.

For more information about the font, read this interview with Robert, and to purchase a license for November 2.0, visit Klemm Music.

SMuFL 1.12 and Bravura 1.12 released

We are pleased to announce the release of SMuFL 1.12, the first update to the specification since the release of SMuFL 1.0 in June of last year. This is a minor update, and as promised does not change any of the code points or canonical names of any of the existing glyphs.

A small number of new glyphs has been added, including two new ranges to extend the repertoire of glyphs in existing ranges that have been filled up, which have been named Time signatures supplement and Octaves supplement (following the conventions used by the Unicode Consortium for such situations).

Two new types of metadata for the glyphsWithAnchors structure have also been added: noteheadOrigin, intended to help with the correct alignment of noteheads of different widths with each other (in particular, the double whole (breve) notehead with two vertical lines to either side of its oval notehead); and opticalCenter, intended to help with the correct alignment of glyphs with noteheads and stems (in particular, glyphs in the Dynamics range). Full details of these new points, including illustrations, are included in the Notes for implementers section of the updated SMuFL specification.

For full details of the changes to glyphs, ranges, and metadata in SMuFL 1.12, consult the version history, or download the updated SMuFL 1.12 specification.

The Bravura font family has also been updated to version 1.12, implementing the new glyphs and metadata specified in SMuFL 1.12. Bravura has in fact been updated several times independently of SMuFL since the release of SMuFL 1.0 in June last year, to fix a few minor bugs, and to improve the design of specific glyphs. In particular, I would like to extend my thanks to Tucker Meyers, who has produced improved versions of the G, F, and C clefs (and their variants), the octave markers, and the digits used for tuplets, which were added in Bravura 1.08 in November last year.

Full details of the changes in Bravura and Bravura Text can be found in the FONTLOG file included in the redistributable package, which contains OTF, EOT, WOFF, and SVG versions of both fonts, together with the font-specific JSON metadata.

Development of SMuFL will continue, as dictated by the needs of its community, and I encourage you to get involved in the ongoing discussion. If you are using SMuFL or Bravura for your project, I’d love to hear about it, so please get in touch to let me know what you’re working on.

SMuFL 1.0 and Bravura 1.0 released

We are pleased to announce the first stable public release of SMuFL, version 1.0. This follows the uneventful release of version 0.99 just over two weeks ago.

There have been only very small material changes made since release candidate version 0.99, which you can read about in the version history. You can browse the complete repertoire of glyphs, or download the specification and accompanying JSON metadata.

Accompanying the release of SMuFL 1.0 is a new release of the Bravura font family, also now at version 1.0, which you can download here.

Now that SMuFL has reached version 1.0, the code points and names of glyphs already included in the standard will no longer change in future revisions, providing a stable base upon which software developers and font designers may build.

Development of SMuFL will continue beyond version 1.0, as dictated by the needs of its community. If you have any requests for changes or additions to future versions of SMuFL, please make your proposal to the community via the smufl-discuss mailing list.

We would like to thank everybody who has contributed to the development of SMuFL to this point, and we look forward to seeing how it is used by software and font designers in future. If you are working on an interesting project that uses either SMuFL or Bravura, please let us know.

SMuFL 0.99 and Bravura 0.99 (1.0 Release Candidate) released

We are pleased to announce the release of version 0.99 of SMuFL and the corresponding version of Bravura. This is a release candidate for version 1.0; it is our expectation that, provided no serious errors or omissions are found in the next few days, this revision will be re-released as version 1.0 with no changes other than in version numbers.

A summary of the changes since SMuFL 0.9 follows:

JSON metadata

  • Modified the specification of the glyphsWithBBoxes structure in the font-specific JSON metadata such that the glyph’s name is the primary key, rather than the value of a name key, which makes it easier to consume this data.
  • Added an optional description key to the sets structure in the font-specific JSON metadata, to contain a human-readable description of a stylistic set.
  • Added a new fourth value to the type key for the sets structure, for large time signature digits intended for drawing outside the staff.
  • Added new graceNoteSlashSW and graceNoteSlashNE anchors to the stem-up 8th flag, and graceNoteSlashNW and graceNoteSlashSE anchors to the stem-down 8th flag, to aid in the registration of grace note slashes with unbeamed 8th notes.
  • Added new repeatOffset anchors to glyphs that require overlapping in order to be drawn correctly, such as the Multi-segment lines and Combining strokes for trills and mordents ranges, which allow correct registration of these glyphs when drawn independently rather than as a run of text (where the advance width of each glyph determines the degree of overlap).

Metrics and registration guidelines

  • Added a clarification in the glyph registration guidelines for fonts intended for use in scoring applications that parentheses glyphs may have negative side bearings to improve default kerning of these glyphs with the symbols they are intended to bracket.

Changes to recommended glyphs

  • Added 8 and 15 digits scaled correctly for positioning on G and F clefs.
  • Added a set of noteheads enclosed in large circles, used by some drummers.
  • Added an ornate X notehead contained within an ellipse.
  • Added Couperin’s pincé and tremblement appuyé ornaments.
  • Added a turned version of the thumb position string technique glyph.
  • Added a zero-width rectangle intended to enclose single percussion beaters inside a box.
  • Added strum direction arrows for guitar, and a stylistic alternate for the golpe glyph as used by Antonis Vounelakos.
  • Added an additional raised 7 digit for figured bass.
  • Added left- and right-pointing arrows for use in metric modulations.
  • Removed the ranges of glyphs for fingering charts for wind instruments.

New optional glyphs

  • Added recommended stylistic alternates for common time, cut time and + intended for use as large time signatures printed above the staff.
  • Added recommended ligatures for combinations of Johnston’s accidentals for just intonation with regular sharp and flat accidentals.

I would like to thank Nicolas Froment and Marc Sabatella from the MuseScore development team for their recent feedback. Joe Berkovitz of Noteflight has also provided very detailed and invaluable feedback on the use of the font-specific JSON metadata for Bravura, and has helped to identify a number of small problems that are addressed in version 0.99.

We are also pleased to announce that the ranges of glyphs in SMuFL are now browsable directly on this web site, in addition to being included in the specification PDF. Individual glyphs displayed on the site are taken from the corresponding version of Bravura, and individual glyphs are annotated with the origin point (to illustrate glyph registration), and any anchor points defined in the Bravura JSON metadata. We hope that this will prove to be a useful resource.

SMuFL 0.99 can be downloaded here, and Bravura 0.99 can be downloaded here.

If you believe you have found a significant error or omission in this version of SMuFL and/or Bravura, please sing out as soon as possible.

SMuFL 0.9 and Bravura 0.9 released

We are pleased to announce the release of SMuFL 0.9, which marks what we anticipate will be the final milestone on the way to a stable 1.0 release. As such, SMuFL 0.9 may be considered a release candidate for the final 1.0 release.

Since SMuFL 0.85, released in March, more than 200 new glyphs have been added, including four new ranges. A comprehensive review of LilyPond’s Emmentaler font has led to the addition of many new glyphs, and survey of important instrumentation handbooks by Ertuğrul Sevsay (Bärenreiter, 2005) and Karl Peinkofer & Fritz Tannigel (Schott, 1976) have led to the addition of a number of new percussion pictograms. New ranges for Kodàly hand signs, Simplified Music Notation and lyrics also provide a good number of new glyphs. As always, a complete list of the changes and new glyphs is available in the version history.

Our hope is that no further glyphs will be added to SMuFL before version 1.0. The deadline to request new glyphs passed at the end of March, and since then the focus has been on completing the work relating to producing guidelines for SMuFL-compliant fonts intended for use with text applications, and the development of a reference font embodying these guidelines.

A set of guidelines for SMuFL text fonts has been completed and can be found in the Notes for implementers section in the SMuFL 0.9 specification. The Bravura 0.9 distribution now includes Bravura Text, a reference font for text-based applications, in addition to the existing Bravura font, a reference font for scoring applications. The distribution also includes a usage guide for Bravura Text, describing how to insert Unicode characters from the font into applications on Windows and OS X, and providing details of specific features of the font, such as the use of ligatures to allow hundreds of symbols (including noteheads, accidentals, articulations, etc.) to be displayed at multiple vertical positions.

Bravura and Bravura Text are now supplied in Embedded OpenType (EOT) format, in addition to OpenType with PostScript outlines, WOFF and SVG.

There have also been significant developments in the richness of the JSON metadata supplied, both at the level of SMuFL itself and in font-specific metadata. The SMuFL metadata distribution now includes a new ranges.json file, which provides information about the glyph ranges as they appear in the SMuFL specification. The glyphnames.json file has been enhanced to include the human-readable description for each glyph in addition to its canonical camel case name.

The specification for font-specific metadata is significantly enriched, with new structures to help expose the repertoire of optional glyphs (in the range U+F400–U+FFFF) of a SMuFL-compliant font to applications, including descriptions of ligatures, stylistic alternates, and stylistic sets. Font-specific metadata may also include a bounding box for each glyph, which could in time help MakeMusic provide automatic Font Annotation (FAN) files for SMuFL-compliant fonts used in Finale.

Full details of all of the improvements in these metadata files is found in the Notes for implementers section within the SMuFL specification.

SMuFL 0.9 can be downloaded here, and Bravura 0.9 can be downloaded here.

With the release of SMuFL 0.9 there are no remaining known work items standing in the way of a stable 1.0 release. If you believe there is something significant that must be considered before SMuFL reaches version 1.0, please raise the issue with the community as soon as possible via the smufl-discuss mailing list.

SMuFL and MusicXML

Michael Good of MakeMusic has posted his summary of last week’s MusicXML community meeting, which took place at Musikmesse in Frankfurt. Fate conspired to prevent me from attending when two successive flights from London were cancelled, so my grateful thanks go to Michael for presenting my slides on SMuFL in my absence, and for taking notes on the issues raised.

It’s hard for me to respond to all of the issues that Michael noted down, as some of them seem to be statements or comments rather than questions, and I don’t have the benefit of the actual discussion to help frame a response. But I will respond to those items that I can, and offer a couple of further thoughts about the ways in which SMuFL might be integrated into MusicXML 4.0.

Font-dependent versus font-independent information

SMuFL itself defines the guidelines for font metrics (including a standard scale factor, namely that the height of the em square should equal the height of a five-line staff) and glyph registration (e.g. that a notehead should be positioned such that y=0 corresponds to the centre of the notehead if drawn on a staff line, etc.). SMuFL also defines the code point for each symbol, and provides a canonical name that can be used by software developers instead of the code point. (This data is made available in JSON format, which is easy for software applications to consume, and easy to convert to and from different structured formats.)

All of the above data is font-independent, i.e. it should be the same for all SMuFL-compliant fonts. This might mean that, were MusicXML’s positioning information relative to these SMuFL defaults (e.g. that a given default-y value should explicitly refer to the position of the glyph baseline, i.e. y=0), some of the mystery about how to interpret these values could be cleared up.

SMuFL also specifies a format for font-specific metadata, which it is recommended that font designers distribute along with their SMuFL-compliant fonts. This format includes values that are similar in scope to MusicXML’s appearance element (for line thicknesses, etc.), as well as per-glyph information about fine positioning details (such as exactly how a stem should connect to a notehead or a flag). Work is currently in progress for further metadata to be included in this format, such as basic glyph bounding box information (including cut-outs from bounding boxes to facilitate basic kerning, e.g. for accidentals), and more detailed information about the repertoire of glyphs in a given font, such as which stylistic alternates and ligatures are included (for those applications that cannot directly access e.g. OpenType glyph substitution features).

It makes sense to me that MusicXML should only concern itself with font-independent information. If a MusicXML file specifies the use of a SMuFL-compliant font in the music-font element, the consuming application has the choice of consuming the font-specific metadata directly itself: this does not need to be encoded in MusicXML at all.

However, if consuming applications could make assumptions about glyph registration and scale factors, as specified by SMuFL itself, it might simplify some of the issues concerning positioning and spacing.

SMuFL and text-based applications

Several questions were raised about whether SMuFL obviates the need for separate fonts designed to work in symbolic applications (e.g. Finale or Sibelius) or text-based applications (e.g. Word or InDesign).

The short answer is, unfortunately, no. This is not specifically a limitation of SMuFL itself, but rather a practical issue resulting from the different needs of symbolic and text-based applications. The fundamental problem is that in order to have a useful and consistent scale factor for glyphs in a symbolic font, it is also necessary to have a very large line height to accommodate very tall symbols (e.g. very short notes and rests), which means that inserting glyphs from such a symbolic font will greatly distort the line spacing of typical text fonts. (It’s not practical to set the font’s basic metrics such that the line height is appropriate for mixing with text fonts when glyphs extend significantly above or below that line height, because different applications, operating systems etc. handle such fonts inconsistently, typically resulting in issues such as glyphs being clipped incorrectly.)

Therefore separate fonts for symbolic applications and fonts for text-based applications are still required. As yet, SMuFL defines a complete set of guidelines for glyph registration and metrics for fonts intended for symbolic applications, but does not yet specify corresponding guidelines for fonts intended for text-based applications, though this is planned to be completed before SMuFL hits version 1.0, together with a reference font that follows these guidelines.

SMuFL does define code points for beams (both in the form of a MetTimes- or Opus Metronome-style preset glyphs that can be combined together, and in the form of generic control characters that can be used by font developers to do complex glyph substitutions to produce more dynamic combinations, if desired), and for things like cresc./dim. hairpins, but without the ability to specify the duration of such things.

SMuFL-compliant fonts are certainly suitable for combining notes and other markings in-line with text in things like tempo instructions, but it will depend on the consuming application and the specific font whether or not it is necessary to use a font designed for text-based applications or a symbolic font in these contexts.

Extending existing MusicXML elements and types

There are a number of areas where MusicXML already defines a wide repertoire of notations where SMuFL defines a larger number. This includes ornaments (the ornaments element), accidentals (the accidental-value type), accordion couplers (the accordion-registration element), percussion pictograms (the percussion element), among others.

One possibility for integration of SMuFL into MusicXML 4.0 would be to draw upon some of the extended repertoire for these notations in SMuFL and expand the MusicXML repertoire accordingly.

Enable access to any SMuFL glyph

One final possibility that had already occurred to me, and which was, I believe, discussed to some extent at the meeting, would be to create a specific element that could be used to declare any SMuFL glyph by its canonical name, rather than having to encode a Unicode code point as an escape sequence.

It is probably not a good idea to try to create a one-to-one mapping between semantic structures in MusicXML and ranges of glyphs or individual glyphs in SMuFL, even though every attempt has been made to provide some semantic information about each glyph included in SMuFL. But it might be useful to be able to refer to a particular SMuFL glyph by name in cases where presently an arbitrary Unicode code point might be used instead.

Discussing further ideas

Discussion about SMuFL itself and its repertoire of glyphs, the specification of its metadata formats and guidelines should be directed to the smufl-discuss mailing list. Discussion about how SMuFL might be integrated meaningfully with MusicXML should be directed to the MusicXML forum.