Author Archives: smufl

Finale v27 released, with SMuFL support

MakeMusic has today released the latest major version of their music notation application, Finale v27. Among its headline improvements is support for SMuFL, allowing Finale users to take advantage of the growing number of SMuFL fonts that are becoming available.

Finale v27 also ships with six SMuFL-compatible music fonts, all of which are licensed under the SIL Open Font License, meaning that they can be freely used with all SMuFL-compatible music notation applications.

With the release of Finale v27, all but one of the major commercial music notation applications now support SMuFL fonts, marking another significant milestone in the adoption of the standard.

SMuFL 1.4 released

The W3C Music Notation Community Group has today published a new revision of the Standard Music Font Layout specification, version 1.4. This new version, the second to be published under the auspices of the W3C, introduces more than 150 new glyphs across five new ranges of characters, and expands the font-specific metadata format, allowing font designers to specify a set of text fonts that are complementary with the music font design (using CSS font selector syntax), and a number of other design-focused items.

The full version history for SMuFL 1.4 can be read here. SMuFL 1.4 is implemented by version 1.392 of the Bravura reference font, which can be downloaded from GitHub.

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


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.