Today I’m at the Music Encoding Conference in Mainz, Germany, where I am giving a presentation on the work I have been doing over the past several months on music fonts for our new application. There are two major components to the work: firstly, a proposed new standard for how musical symbols should be laid out in a font, which I have called the Standard Music Font Layout (SMuFL to its friends, pronounced with a long “u”, so something like “smoofle”); and secondly, a new music font, called Bravura. Read on for more details.
SMuFL
One of the (many) barriers to interoperability between different scoring applications is that there is no agreement on how music fonts should work, beyond a very basic layout that dates back to the introduction of the first music font, Sonata, which was designed nearly 30 years ago by Cleo Huggins (@klyeaux) for Adobe.
Sonata uses a mnemonic approach to mapping. From the Sonata Font Design Specification:
The encoding for Sonata is intended to be easy to use for a person typing… The symbols are typically either visually related to the key to which they are associated, or they are related mnemonically through the actual letter on the keycap. Related characters are typically grouped on the same key and are accessed by using the shift, option, and command keys to get related characters.
For instance, the q key is associated with the quarternoteup glyph, Q (or shift-q) with the quarternotedown character, option-q with the quarternotehead character, and so on. The treble clef is located on the ampersand key (&), because it resembles an ampersand.
In general, the shift key flips a character upside down, if that makes sense for a given character, and the option key selects the note head equivalent of a note. There are many instances where this is not possible or practical, but there is a philosophy in its design that will become evident and will allow a user to easily remember the location of most of the characters in the font.
Fonts that followed in Sonata’s stead, such as Steve Peha’s Petrucci, the first font for Finale, and Jonathan Finn’s Opus, the first font for Sibelius, initially adhered reasonably closely to Sonata’s layout, but pretty quickly they began to diverge as the applications matured, and there was no agreement on how to map additional characters.
As hundreds of new symbols were added to these font families, and new families were added, there was no standardisation at all. The Opus family, for example, now has hundreds of glyphs spread over 18 different fonts, but there is almost no overlap with how many of the same symbols are laid out in, say, Maestro or Engraver, the two font families most commonly-used in Finale.
In 1998, Perry Roland from the University of Virginia proposed a new range of symbols to be added to the Unicode standard for musical symbols, and the range of 220 symbols he proposed was duly accepted into the standard, at code point U+1D100.
Unfortunately, although this range represents an excellent start, it has not caught on (to date, the only commercial font that makes use of the Unicode Musical Symbols range is the OpenType version of Sonata), and it is in any case insufficiently broad to represent all of the symbols used in conventional music notation.
So these are the problems that I set out to solve with the Standard Music Font Layout, or SMuFL: to map all of the symbols used in conventional music notation into a single Unicode range; to allow for easy extensibility in the event that new symbols are dreamed up or there are omissions; to provide a framework for the development of new music fonts; and to develop a community around the standard, so that the wisdom of experts in different fields of music can be brought to bear.
If you want to find out more about SMuFL, you can visit its own web site at www.smufl.org.
Developing a standard like SMuFL is all very well, of course, but to make it real and useful, there need to be music fonts that demonstrate the standard: enter Bravura.
Bravura
The above image shows Bravura in action: it’s the first two bars of Fibich’s Nálada (Op. 41, No. 139). You can click on the image to see a larger version, or you can download a PDF of the whole page. (The music is set in Sibelius, rather than in our new application, by the way.)
The word “Bravura” comes from the Italian word for “bold”, and also, of course, has a meaning in music, referring to a virtuosic passage or performance; both of these associations are quite apt for the font. In keeping with our desire to draw on the best of pre-computer music engraving, Bravura is somewhat bolder than most other music fonts, as this comparison of the treble (G) clef shows:
Bravura’s clef is the rightmost clef in the above example. It has a very classical appearance, similar to Opus, Sonata and Maestro, but more substantial than all of them. (Emmentaler, the most stylised of the clefs above, is the font used by Lilypond and MuseScore.)
Here is another comparison, showing the eighth note (quaver) from each of the above fonts:
Again, Bravura is the rightmost example. The notehead is nice and oval, though not as wide as Opus (an exceptionally wide notehead), and relatively large in comparison to the space size, aiding legibility. The stem thickness is also boldest for Bravura, though this is only the precomposed note from the font; when a music font is used in most scoring applications, the stem thickness can be adjusted by the user.
Here are a few other symbols from Bravura, to illustrate its classical design:
That rightmost symbol is the percussion pictogram for sandpaper blocks, by the way. The small, semibold numerals immediately to the left are for figured bass.
You will notice that there are few sharp corners on any of the glyphs. This mimics the appearance of traditionally-printed music, where ink fills in slightly around the edges of symbols.
All of the basic glyphs were modeled after the Not-a-set dry transfer system, as mentioned in a previous post. Originals were scanned, examined at high magnification, and then hand-drawn using Adobe Illustrator by yours truly. I have shared the resulting designs with a number of expert engravers, who have given me invaluable feedback on details large and small, and many of the symbols have already been through many revisions.
The result of many hundreds of hours of work, I hope you will agree that Bravura gives a very fine, classical appearance. There is still much work to do, since our own application is not yet at a sufficiently advanced stage of development that all of the glyphs in the font are being used, and there are details such as ligatures and stylistic alternates to be considered as well. But we are making Bravura available now in support of the effort to continue developing SMuFL.
Even better, Steinberg is making Bravura available under the SIL Open Font License. This means that Bravura is free to download, and you can use it for any purpose, including bundling it with other software, embedding it in documents, or even using it as the basis for your own font. The only limitations placed on its use are that: it cannot be sold on its own; any derivative font cannot be called “Bravura” or contain “Bravura” in its name; and any derivative font must be released under the same permissive license as Bravura itself.
If you use Finale or Sibelius and want to use Bravura for your own scores, unfortunately you cannot use the font unmodified, as neither Finale nor Sibelius (yet?) supports SMuFL, and there are technical restrictions on accessing the font or characters at the Unicode code points where they exist.
Nevertheless, if you would like to download Bravura to try it out, you can do so from the SMuFL web site.
If you are a font designer and you would like to contribute improvements or modifications to the glyphs included in Bravura, we’re definitely open to including them: just drop me a line with details.
Very interesting. The point being how the font is constructed, not whether it looks particularly different to existing ones. Steinberg created a standard with asio, I guess they can do it again.
Back in the Atari ST days, I invested a not inconsiderable amount of money in Masterscore – a notation add-on for Steinberg’s Pro-24 sequencer that disappeared without trace. Will there be an upgrade path? Not that there’s any evidence left of my owning it I fear! Just MAYBE I kept the dongle?
That you are releasing this font under the open font license is outstanding.
I also very much like the extra thickness of the font. Balancing adequate barline ledger and staff line weights with character weights has been a challenge for years as dpi of printers increase.
Looks amazing!
Thank you for releasing this font early, Daniel! I very much like the appearance of all the glyphs I have examined so far. If this is an example of the attention to detail that you and the rest of the team are working on with this new notation program, I am more eager than ever to see the final products. How can a person get on the beta-testing team?
@David: I’m very glad that you like the look of Bravura. It has been a labour of love, as well as one of necessity. We’ll definitely let everybody know when we are looking to recruit some beta testers.
I’d certainly be one of those people interested in beta-testing when the time arrives. I’m very much looking forward to seeing the further developments on this project. 🙂
Hello,
I would be very honored to help you as a beta tester.
If you are interested you can contact me.
Bravo Daniel! Well done in every way.
Very exciting to read about this, and I’m so glad you’ve decided to release this under an open license. I think the boldness of Bravura may take some getting used to. The stem of that eighth note means business! 🙂
In general, though, I think it looks quite beautiful. The glyphs you showed here are very nice. I like that even with the bold font, there’s still a bit of whimsy and character (trill).
hey Daniel how are you doing? Remember me?:-)I notice a little “bleeding”(probably because of the boldness of the font) on the g and b’s under the ledger lines,can that distance be adjusted? or maybe it is my astigmatism ?:-)but it is a nice font for sure, congratz!
@Carlos: That “bleeding” is intentional: the notehead is the largest possible size it can be relative to the space size. I went back and forth with a group of expert engravers on the precise size and shape of the notehead until we found a mutually agreeable one.
Excellent. You seem to follow the same basic principles as Lilypond for the fonts – slightly rounded corners like classic printing, good thickness for readability – but you extend them further. The preliminary result makes the note reading faster already. It also makes the score feeling more «assertive» than the classic Opus Font (Personally, I always found the noteheads of Opus too wide, so this new font sure is a good thing for me.)
Thumbs up for the Open Font licence !
I am also interested to be a beta tester, of course 😉
Thanks for this exciting news, Daniel! But – if the font can’t be used in Finale or Sibelius, how did you manage to set your nice example in Sibelius? Or is this a specially modified version of Bravura to conform to Sibelius’s mapping?
@Philip: Yes, I produced a Sibelius-compatible version of Bravura for testing purposes, though it’s a bit rough and ready compared to the main Bravura font itself.
Is there a way to try out the Sibelius-compatible version of Bravura? Unless you know of a program that will work with the new SMuFL system (and thus the downloadable Bravura)?
This is so exciting that I really want to see the font in some serious action. I have some Stravinsky in LilyPond format that would look lovely in Bravura, too.
Looks fantastic, Daniel Remember you if/when you run out of beta testers!!! Regards
Bravo, Daniel! These glyphs are so “meaty” and organic-feeling… I can’t wait to start seeing real-world examples.
Oh, and sign me on for the Beta. =)
I’m very exited about what you are working on with the Bravura mr. Spreadbury. It looks great! The best font until now is for me November from Klemm, but I might change my opinion.
Hi Daniel – this may not be the time or place for it – but with previous notation software we were unable to have multiple key signatures vertically in the same measure – B flat in a flute, G major in a oboe – etc… Also, in that same flute line say you want to be in 7/8 and the oboe 3/4 without too much effort. Can I put the thought in that maybe your new product could have a “Graphic” mode where these options are possible – with or without playback? *I* would never use it, but I know composers still doing that complicated stuff…
@Bob: In fact you can have different key signatures in different staves in Sibelius. That will definitely also be possible in our new application.
You may be interested to know that LilyPond supports polymetric notation quite well. See examples in the manual:
http://www.lilypond.org/doc/stable/Documentation/notation/displaying-rhythms#polymetric-notation
Hi Daniel. Excellent approach and elegant design. What are the chances of taking the text values from this font and creating or adapting a real music text font, like those used in Peters and Bärenreiter scores, rather than versions of Times Roman? I’ve been dissatisfied for many years at the lack of such a basic resource in notation software. The inclusion of such a font in your software would make a huge difference to its look and appeal, as far as I’m concerned.
@Thomas: There are some good OFL-licensed cuts of classic text typefaces available, and we may well include some of those with our new purism. I think Bravura looks especially nice when paired with Century Schoolbook, as in the PDF example I’ve shared, and there is a decent OFL cut of that font in the TeX Gyre collection. So this is definitely something we are thinking about.
Thanks, Daniel! I think the difference is in having a typeface that is clearly the plain italic version of the standard bold-case “p” and “f” that’s taken for granted. For indeed this dynamic text is not a font in and of itself. It is derived from a standard music text font, slightly stylized, but basically the same characters.
The problem is that a notation software-generated edition will immediately be recognizable by its use of Times Roman-type expression text fonts. After 18 years of this, I think it’s time there was something that looked professional.
LilyPond uses Century Schoolbook as well – it’s nice and has this “classical, early XX century look”. The only drawback is that it’s not optimal for lyrics in languages containing long syllables (such as English or German) because it’s quite wide.
By the way, there was a discussion in LilyPond community about creating a Free font designed specifically for music engraving. It was considered a good idea, but we lack enough funding currently. Maybe we could do this together with Steinberg?
If you’re interested in that discussion, take a look:
http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00262.html
http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00382.html
Good.
Yes indeed!
I consider TNR a nasty font, useful for narrow justified columns in newspapers but in most applications cramped and often difficult to read, especially for words with lots of ‘m’s, ‘w’s, ‘n’s, ‘u’s … When editing academic text, I always switch away from TNR to a font that’s easier to read, and if it takes 5% to 10% more space, well tough.
These days I generally use Cambria, which supports an immense number of glyphs across a huge language spectrum, including IPA.
Like Bravura …
Enjoying this discussion.
Props for the licensing, and for the design, it looks quite nice!
@Daniel: I created a Sibelius-compatible version as well. I just looked at the Opus Std font and replaced the symbols piece by piece with Bravura. I got the hang of it, because I did the same with the problematic font November. I really like the boldness of it. Lot’s of black. This one will probably be my one of my favorites next to November and Vienna.
Don’t know if I’m allowed to share my compatible version.
Mano
Very exciting to get these updates and I really do like the “very fine, classical appearance” of Bravura. Thanks Daniel for all your hard work and outreach.
Wow, this is one beautiful font design. Congrats, Daniel, on your awesome, thoughtful, and well-informed work!
Daniel,
Great work!
BTW: SMuFL-0.4 document, page 50, cymbals (edge and bell) are inverted 🙂
I Wish To Learn More About Music The Musical Notes And More and Insturments
Congrats to your project, Daniel! Even though its in German, maybe you should have a look on the German Wikipedia scorewriter article in a free minute (http://de.wikipedia.org/wiki/Notensatzprogramm). You certainly know everything written there, but never the less, to my mind, it’s an outstanding and comprehensive overview of the topic of music notation software. Google translater an leo.org are your best friends… 😉
Have a look again at the sfz. The distance between the letters is uneven. The z too close to the f. Is this intentional? Otherwise it looks great.
Really? Looks fine to me…
Congrats Daniel, this is amazing work and will make great standard notation much more accessible to software as a whole. Thanks a lot for publishing this under an open license and being open to collaboration.
The slightly larger dimensions of the characters are welcome. How can these innovations be applied to SCORE?
@Don: I’m not sure, I’m afraid! I don’t know how you would go about taking outlines from a font and turning them into a library of symbols etc. for SCORE, but that is perhaps something you can discuss with experts on the SCORE mailing list.
Hi Daniel, if “interoperability” is the keyword, I can just support the cause. I will examine carefully all existing sybols in the font Bravura. (actually, this post persuaded me definitely to suscribe to your news).
Talking in general, I suggest a (new?) font for the clefs. You know the little eight below the G-clef to denote “sounds 8ve lower”. Well, I propose a small 2 below to denote “transposing clef, sounds a second lower” for clarinet, trumpet or any other B flat instruments – what do you think? Also a small 9 for bass clarinet, etc.
I actually use these clefs in my own music and find it particularly practical when there is no tonality, so erradicates the question “is it written in C, or transposing?”
warm regards
Juan María
@Juan Maria: I have had different numerals below various clefs to show transpositions other than octaves up and down suggested to me by another engraver, so this is something I will give some consideration to.
While you’re at it, can you *please, please, please* look again at the behind-the-scenes pitching of the trebletenor clef? Music input with a proper C4 tenor clef and then converted goes DOWN an octave…
@Juan Maria: This is a good idea! I’ve been thinking about it as well.
However, i don’t think it would make sense to have wagonloads of clef glyphs in the font – i suppose that the transposition should be a separate element.
Count me in for beta testing. I’ve been working notation programs to their extremes for 15 years… And I mean contemporary articulations, jazz articulations, lyrics, millions of lines, chord symbols, graphs, etc… The only thing I’ve never used is TAB.
Hopefully you will find my input useful.
All the best!
As both a graphic designer (with an almost obsessive interest in typography and font design) and a power Finale user I found your article most interesting. I can’t wait for a Finale-compatible version to be released. The font looks beautiful, and thanks for a thoughtful and informative essay.
Your new font looks really great! I like the boldness / sharpness. Do you think you might come up with an equally dynamic figured bass font, such as the one here http://lilypond.org/doc/v2.16/Documentation/notation/figured-bass for example… Thanks!
I second this – and although it’s early days, could you consider an easy way to deal with figured bass extension lines in the new program, as Sibelius leaves a lot to be desired in this regard!
Great! The flag of the 8th note could have a little more roundness. For me it looks too tame.
@Daniel: great that we are more than one)!
@Janek: actually you are right, but even if you had -say- horns in D flat or in just D, the main idea is to indicate that the score/part is NOT in C.
Horns are possibly the only instrument with several possible transpositions (mainly for historical reasons). Although I cannot recall any piece for horn in E (and several in E flat) it might be possible that they exist (and a fast search would seal my mouth for ever). So your suggestion is meaningful – while restricted to a few pieces in the literature. (By the way, besides piano I played horn as second instrument for some years)
warm regards
Juan Maria
@Juan Maria: Indeed, e-natural transposition is rare. In fact, in every case it should be pretty clear whether the interval denoted next to the clef is minor or major:
– a second is virtually always a major second (i.e. there are transposing instruments in b-flat and d-natural, but there are virtually no instruments in b-natural and d-flat),
– a third is virtually always a minor third,
– a sixth is virtually always a major sixth,
– a seventh is virtually always a minor seventh,
– a fourth, fifth or octave is virtually always a perfect one.
So, there is actually not that much ambiguity, and i agree that marking transposed clefs with an appropriate number would be a great improvement.
best wishes,
Janek
Just wanted to say I think the work you’re doing is excellent. The music community will be very grateful when this project is finished!
@ Janek: In large orchestral scores, using additional numbers may require too much vertical space (unless they are so small, that they actually cannot denote anything), so it is better to draw them as a part of a clef (ligated, just like 8 for tenors, which, in some older editions of choir music, goes instead of the terminal dot), thus, have them encoded.
@Juan Maria: It happened to me, that in a score I prepared for publication, I used a treble clef transposing augmented fourth down, as the composer wanted the entire movement to be played on stopped horn (transposing clefs were employed in the previous volumes of the publication, and I wished the rule to be followed).
About 120 glyphs can cover most cases (including contrabass clarinets in both clefs, differentiating between E and E-flat transposition, and even augmented unison, for the exceptional case that an old instrument tuned to a=415 is used in a modern composition). And 120 glyphs are not so many. There are more than 100 accented characters for European languages.
Thank you, Daniel. This is all amazingly great news!!
Dear Mr. Spreadbury,
It’s nice to see another music font on the scene, especially one that is looking to create an open and standardized font! Thank you for that!
One point I slightly disagree with, though it amounts purely to a matter of taste, is in the use of thick weights of notational elements. Personally, I prefer a slightly lighter font, which creates a different psychological impact for the performer (particularly with complex scores of new music). This has led me, over the past few months, to begin developping my own font. I would love to discuss SMuFL and Bravura with you, as well as contributing what I can to the project.
Best wishes and thank you for this!
@Alexander: There’s obviously room for lots of different music fonts with lots of different visual styles. If you’d be interested in making your font SMuFL-compliant, that would be great! You are more than welcome to join the smufl-discuss mailing list and to participate in the development of the standard.
@Emil:
I think there may be a misunderstanding: I didn’t mean that there should be a gap between the clef and the number (like this http://www.freeimagehosting.net/c5p3h). I suggested that the clef and the numbers should be separate glyphs in the font – that way the user will be able to customize the appearance of the transposition number (for example change its size, color, make it bold or italic, or anything he wants). If transposition numbers were part of the clef glyphs, this would be much, much harder to do.
Of course, with numbers being separate glyphs it will be possible to attach the number to the glyph so that they touch or overlap, or anything you want.
As for the ligated 8 that replaces the bottom dot, that’s an interesting idea, but i still think that you shouldn’t do this by creating 120 glyphs of clefs with transpositions hard-coded in them. It should be enough to have 14 or so glyphs:
– 10 digits,
– 4 clefs (F, C, G and a variant of the treble clef with the dot cut off, so that it could be replaced by the transposition).
Here’s a proof of concept: in LilyPond, the clef and the transposition number are separate glyphs. I was able to customize the appearance of the transposition number quite heavily, as you can see here: http://www.freeimagehosting.net/cv5fb (this wasn’t done by image postprocessing – it was done in LilyPond itself!).
By the way, how did you notate the augmented fourth transposition? Was it 4+ or 4< or something else altogether?
best wishes,
Janek
@Janek: Okay, I think that’s getting towards your limit for Lilypond evangelism on this blog for this week. Thanks!
@Daniel: Sure, thanks for telling me. I’m grateful for having the opportunity to speak here and i wouldn’t want to hijack the discussion.
Keep up the good work! I’m glad to see that your app will have nicer font than those shipped with Finale and Sibelius 🙂
The notation for stopped horn was actually a diminished 5th (it is still an F horn, just risen a semitone up), written, after many considerations, as #5, which I found most consistent with other elements of notation. For common transpositions like 2nd or 6th we use just a digit (although a saxophone player asked, why a flat sign disappeared, as it is E-flat or Mi-bemolle). For E transposition I would use a 6 with a natural sign (however, I have published a reedition of some 19th century music, with 6> marking, now I find this notation confusing).
Basically, I agree with you, that the apps should deal with transposition numerals as an separate, fully adjustable element. But imagine a conducting score with alto and bass flute, cor anglais, three clarinets, 4 horns, 2 trumpets (each instrument on a separate staff for good reasons, as the musical texture changes rapidly) and immensely divided strings, printed on an A3 or even 450×320 mm paper. In this circumstances each millimetre is precious, and staff size may go less than 4 mm (which is in practice the smallest staff size for that type of score). At this staff size, transposing numerals would need to be almost 2 spaces high, to be visible enough. This equals to about 15 spaces you must provide. In some circumstances it really makes a difference. And only the last of your examples can address this issue. Now, it would look some better if the elements were ligated (not to mention the stroke contrast in the digit). And for ligated sign one has to have codepoints (well, there are OpenType alternates, but I think that only glyph to glyph substitutions can make sense for engraving music).
And I suppose, that for programmers it would be the most convenient way to deal with this kind of notation: to make an option, that in the transposing score the instrument uses a clef from given codepoint.
For this reasons I’m nearly sure, it is a good Idea to have these clefs encoded. And this works on that way even today: in Sibelius you can tweak instrument definitions, saying the application to use an ordinary treble clef for clarinet in non-transposing score, and a 8vb clef when switched to transposing mode. Then, if you substitute the 8vb clef with “seconda bassa” one, the score behaves perfectly, and you are able to easily make printouts both in concert pitch and transposing, with properly marked transposition, to meet the preferences of the different persons involved in production.
@Emil: i see your point. Maybe it would indeed be better to have these clefs encoded… I’d have to see some scans.
I’ve made a Sibelius-compatible version (I know I’m not the first), look here for it: http://amoschou.net/.
Hello Daniel,
thanks a lot for sharing your work in an early stage of development. It is high time that music notation fonts use the designated unicode areas and a common standard layout. Thanks for finally dealing with the problem with SMuFL.
As a font designer, I have always been disappointed with the poor outline quality by the existing fonts around. I must say, Bravura isn’t really an exception to that. I will work on a few proposals…
Thanks for sharing this. The world did need a thicker, “inkier” font. Like Alexander said, a lighter SMuFL font will eventually be helpful as well.
Are you guys planning on creating or adapting a “jazz” font as well? This one looks good so far.
@Mike: Yes, I expect that there will be a font with a handwritten appearance in the fullness of time!
Daniel — I found this posting (as well as the others so far in the blog) fascinating, confirming what my wife has always thought, I am a music geek. Fascinating reading!! Please keep up the posts!
Good luck with the project! I really like the thick stem on the quaver. The thicker stems (and staff lines) was always one of the reasons I sometimes actually preferred Cubase’s notation printouts over Sibelius. It just seemed more practical and clear, easier to get the job done if the goal is to get readable music, not necessarily “pretty” music.
Btw, I hope you can preserve Cubase’s great ability to intelligently translate MIDI data to musical notation. That’s one area where Cubase’s score editor still totally kicks Sibelius’s backside. My favourite trick is to set display quantization for rests to double the length it’s for notes, and syncopation magic set to maximum. For example, notes 1/8 and rests 1/4, if the melody has an eight-note pulse. Then it practically always produces the correct notation with zero need for manual adjustments. Granted, manual adjustments are easier in Sibelius, but it always requires lots of them, whereas Cubase usually doesn’t need any at all, once I’ve set the display quantize values appropriately.
Hi,
I hope I didn’t overlook a reference to my question in that big number of comments …
How will the glyphs be identified/organized/accessed in the OpenType fonts according to SMuFL?
In the SMuFL reference I see each glyph accompanied by two (alternative) Unicode numbers (e.g. ‘U+E040’ and ‘U+1D106’) plus a descriptive text like in this case ‘Left repeat sign’.
Does this mean there is no notion of ‘glyph names’ that the OpenType standard offers?
The above glyph could for example be called by ‘smufl.barlines.repeatleft’.
Am I missing something?
Is this left out on purpose?
Is this left out accidentally?
Is this planned but not realized yet?
I think it would be a very good idea to be able to access SMuFL glyphs by name. I find this quite descriptive in use.
(For example I’m developing a package to include notational elements as characters in LaTeX documents, and I would be happy to extend this one day to be SMuFL compliant)
@Urs: The recommendation for SMuFL-compliant fonts is that they should follow the glyph naming conventions set out by Adobe (in the AGLFN), since these are popularly followed by operating systems and the major applications (particularly those from Adobe) with regard to font embedding, etc. What this means is that glyphs in the Private Use Area of the Basic Multilingual Plane, where SMuFL lives, should use glyph names of the form “uniE000”, i.e. “uni” followed by a four-character hexadecimal representation of the code point; SMuFL also recommends that compliant fonts include glyphs in the Unicode Musical Symbols range, between U+1D100–U+1D1FF, and the recommendation for glyph names in that code range (beyond the first 16 bits in Unicode) is of the form “u1D100”, i.e. “u” followed by a six-character hexadecimal representation of the code point.
However, this does not prevent consuming applications from maintaining a mapping between the SMuFL code points and identifiers such as those you propose, e.g. “smufl.barlines.repeatleft”. Indeed, one thing that has not yet been completed related to SMuFL is a metadata file that will provide some hints (which I don’t mean in the technical sense of font hinting, but rather just helpful information) to consuming applications, and among other things it could indeed provide some suggested names for consuming applications to use as a means of accessing its symbols.
If you’re interested in discussing SMuFL in detail, you’d be very welcome to join the smufl-discuss mailing list. Likewise, if you spot any symbols missing from SMuFL that you think should be included, please let me know.
The notes are too fat – typical American ‘bigger is better’, no, its illegible and on ink jet printers this could make the blobbyness even worse. It looks like overloaded printing from 100 years ago.
I absolutely agree with you. I wrote a detailed comment, but seems it was never published…
Just wanted to say that Bravura (under the name of Profondo) can now be used with LilyPond too: See http://lilypondblog.org/2014/09/lilyponds-look-and-feel/
The font looks great but the following characters do not produce the desired results.
10 x wiggleWavy does not produce a correct sine wave
10 x wiggleSawtooth does not product the correct sawtooth wave
as portrayed on page 245 in smufl-1.0.pdf
Shouldn’t the characters should be start along the center axis traveling upwards first.
@Don: These glyphs tesselate okay for me. Here is a screenshot, grabbed from TextEdit on my Mac, of Bravura at 64pt, with two sequences of U+EAB5 (wiggleWavy) and U+EABB (wiggleSawtooth), which look good to me.
Yes they look this way but that is incorrect according to page 245 in the manual. The manual shows it the most common way. Sine, saw, square, etc. waves are usually drawn starting on the horizontal axis and go the the peak and then down.
If you do a search on the internet for sine wave image you’ll see that 90% of the images are this way.
Sorry but I forgot to mention one more unrelated thing. The font has play, stop, rewind, skip, etc. buttons. Shouldn’t it also have a record button.
BTW, I am loving the whole SMuFL thing. Thanks for creating Bravura and I hope others follow. I am almost done converting my own font to SMuFL.
@Don: The reason we don’t have a “record” character in SMuFL is, for better or worse, that we didn’t consider it likely that people would be recording during a musical performance: the play/stop/rewind etc. buttons were intended to be used as part of instructions for e.g. tape or sample playback as part of an electro-acoustic or electronic music performance.
Thanks for pointing out the inconsistency between the example of 10 x wiggleWavy and the current version of the wiggleWavy glyph. I’ll update the graphic to match the glyph when I get a chance. Bravura is just one possible embodiment of the SMuFL standard, of course, so other font designers are free to construct their tessellating sine wave glyphs however they wish.
Well, if you are talking about electroacousting performances, recording is nearly as probably as playing back. I’ve seen this with computers as well as with vintage tape recorders.
Hi Daniel,
The font looks very nice, but I found that on iPhone with Korean language, the quarter note becomes much thinner. It happens only to Korean, not even Chinese and Japanese. Could you please shed some light on this problem? Thanks a lot!
Tao
@Tao: I’ve really no idea what could be causing that. Can you contact me by email with some screenshots etc. so I can get a sense of what might be happening?
Excuse my ignorance, but I’ve downloaded the Bravura font file, now how do I install it? I’m using Finale 2012c.r13 on Windows 10.
@stbedesantafe: Bravura won’t work with Finale as-is: you need a specially modified version of Bravura modified for use with Finale. I believe it’s called Fravura, and you can find it here.
Another alternative for using Bravura in Finale is “Aruvarb”. It is 100% Maestro compatible and has all glyphs from Bravura in the unicode area. Fravura only has a limited character set and isn’t fully compatible with Maestro. It is available at https://elbsound.studio/elbsound-music-font-package-for-finale.php.
Please…. How to instal bravura
@Cyril: On Windows, you can simply drag the Bravura.otf and BravuraText.otf files to C:\Windows\Fonts. On Mac, you can copy them to /Users/your-user-name/Library/Fonts.
The glyphs in the Bravura font for
U+01D123 MUSICAL SYMBOL F CLEF OTTAVA ALTA
U+01D124 MUSICAL SYMBOL F CLEF OTTAVA BASSA
have a small 8 floating way above the F clef for the ALTA variant, and a small 8 just touching the top for the BASSA variant. Shouldn’t they be just touching the top of the F clef for ALTA and the bottom for the BASSA?
I’ve spoken to a music notation expert who says that the two glyphs in Bravura are wrong. The OTTAVA BASSA clef is used rarely, but sometimes for very bass instruments such as the contrabassoon.
@Doug: Please bring your issue to the Bravura GitHub project.
Sonata is the one which Noteflight.com uses.