|
|
| MakeMusic Forum > Public Forums > Finale - Macintosh - FORUM HAS MOVED! > The new notation program? | Forum Quick Jump
|
 |
Knut
Registered Member
      
Date Joined Jan 2006
Total Posts : 601
| Posted 11/8/2016 3:59 AM (GMT -6) |   | As a font designer, I can't for the life of me figure out why SMuFL is controversial. It's primary objective is to standardize glyph mapping for any musical symbol in the literature, which surely benefits both software designers and users.
SMuFL does not stipulate any mandatory glyphs; it only recommends them, so the scope of a SMuFL font is entirely optional. It is true that it can be very hard to find a single symbol in a huge SMuFL font. However, the mapping is entirely systematic; the glyphs are sorted in categories and follows an entirely standardized naming scheme which facilitates the implementation of improved search and navigation functionality within the software itself.
Beyond glyph mapping and naming, SMuFL includes an extended set of glyph metadata, including registration, spacing, bounding box coordinates and coordinates for stem connections, optical centering of dynamics and cutouts in accidentals and other shapes. This metadata set eliminates the need for font annotation files and application specific stem connections, and may be used by software developers to improve an application's placement and spacing functionality.
The SMuFL specification is a joint effort, initiated by Steinberg, developed and maintained by the W3C Music Notation Community Group and chaired by Michael Good (MakeMusic), Joe Berkowitz (Noteflight) and Daniel Spreadbury (Steinberg).
13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3 | | Back to Top | |
|
Robert P.
Registered Member
Date Joined Apr 2004
Total Posts : 1691
| Posted 11/8/2016 5:55 AM (GMT -6) | | | |
|
tisimst
Registered Member
Date Joined Feb 2015
Total Posts : 18
| Posted 11/8/2016 12:56 PM (GMT -6) | | +++1! A couple of thoughts as the topic of SMuFL has come up...
Knut said...
As a font designer, I can't for the life of me figure out why SMuFL is controversial. It's primary objective is to standardize glyph mapping for any musical symbol in the literature, which surely benefits both software designers and users.
I personally agree with you, Knut, but I can see how management/developers who are trying to find ways of keeping market share would not want to get away from their own model/format/encoding. "Why would I make it easier for someone to use it on the other guy's software?" I'm only guessing this is really the line of thinking, but it's a possibility. The other logical issue is code refactoring to using a different font encoding. This is no small task. I can understand some hesitancy there. And what about backward-compatibility with program versions that don't support SMuFL? That can be another tricky feat to tackle smoothly.
Knut said...
Beyond glyph mapping and naming, SMuFL includes an extended set of glyph metadata, including registration, spacing, bounding box coordinates and coordinates for stem connections, optical centering of dynamics and cutouts in accidentals and other shapes. This metadata set eliminates the need for font annotation files and application specific stem connections, and may be used by software developers to improve an application's placement and spacing functionality.
At first I wondered if SMuFL would catch on, but I think it has become clear it is here to stay. The more I think about it, the more I realize SMuFL is heaven-sent for us designers. It makes font maintenance MUCH easier and gives us the ability to better support each application and more users, making more elaborate fonts available for everyone! I am a huge fan of SMuFL.
N. Grossingink said...
That's likely to be a big/impossible hurdle for publishers and individuals who favor a custom or 3rd party font.
Maybe big, definitely not impossible. There are a good handful of us that have experience working with 3rd-party fonts and what's involved in converting them to/from the SMuFL encoding. Publishers and individuals can always reach out to one of us if they need help doing that. | | Back to Top | |
|
OCTO.
The radical answers.
Date Joined Jul 2008
Total Posts : 2659
| Posted 11/9/2016 12:20 AM (GMT -6) | | I am not against SMuFL, as said, I have mixed feelings. What you all say above I agree with.
On the contrary, the main SMuFL problems I myself see is the following:
- zero compatibility with old files;
- not developed by community in the strict sense - as long as you have the leaders who are interested in their commercial product, it is not. It is not like Debian - no commercial interest by a company. I see here a strong interest from Steinberg/Dorico;
- extreme ranges - unless it is developed a "music"-language keyboard, it is very hard to use it outside of one product (Dorico); very hard to use in Word, or Sibelius etc.
- repetitive symbols found over again;
- a monster size font table, imitating Unicode of everything possible, but hey - who will ever use g clef with 0?
- the border between musical and non musical symbols is not clear;
- how will other types of notation be used, such as indian, byzantine? What software?
- as an engraver or composer you will perhaps need one symbol that is not found in SMuFL: you can apply for that symbol to SMuFL, if rejected (very possible) you need one font MORE to use in your music, or tweak already existing font;
- The Main Question: why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges? Why cannot f be typed as a keystroke f?
I know that Daniel S is coming from Sibelius where they struggled with symbols spread across many fonts, but this, is in my opinion, as well extreme.
Another feeling about just Bravura: it is not a balanced and well designed font. Some symbols are very beautiful another are just plain ugly. It is my personal opinion.
Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAMPost Edited (OCTO.) : 11/9/2016 12:34:29 AM (GMT-6) | | Back to Top | |
|
Knut
Registered Member
Date Joined Jan 2006
Total Posts : 601
| Posted 11/9/2016 3:57 AM (GMT -6) | | OCTO. said...
- zero compatibility with old files;
That's true, but it doesn't prevent you from keeping your old fonts installed, so this argument seems irrelevant to me.
OCTO. said...
- not developed by community in the strict sense - as long as you have the leaders who are interested in their commercial product, it is not. It is not like Debian - no commercial interest by a company. I see here a strong interest from Steinberg/Dorico;
Which industry standards are, really? I'm not an expert in the tech field, but my impression is that the vast majority of software and hardware industry standards are fueled by some kind of commercial interest and developed by either established or entrepreneurial entities. As I've stated previously, SMuFL is a joint effort between a large community of engravers, publishers and software developers, lead by representatives from MakeMusic, Noteflight and Steinberg.
OCTO. said...
- extreme ranges - unless it is developed a "music"-language keyboard, it is very hard to use it outside of one product (Dorico); very hard to use in Word, or Sibelius etc.
If SMuFL indeed is widely adopted, this is a passing issue that quickly will be solved by software developers. Any software which supports SMuFL needs to provide the means of symbol selection from any supported glyph categories. As the need for these means become apparent, this issue will likely take care of itself.
OCTO. said...
- repetitive symbols found over again;
This seems to be a recurring argument whenever this topic is discussed. As I've said before, duplicate symbols in SMuFL is the natural result of it's structure, and is also closely related to concerns about accessibility. One example is microtonal accidentals, which has been represented in many different ways at different times and by different composers. There really isn't one single system which has caught on enough to exclude all others. Yet, very few of these systems are entirely unique; they usually build on the traditional accidentals or some other related system, which means that many of the symbols will be the same across different systems. How, then, should a font be structured if not by category? And if no duplicate symbol was allowed in a font, in which category should common symbols reside?
Of course, any font designer is free to exclude any duplicate symbol if so inclined. Bravura has to include them, though, to fulfill it's purpose of being a showcase for the entire SMuFL range.
OCTO. said...
- a monster size font table, imitating Unicode of everything possible, but hey - who will ever use g clef with 0?
How would you suggest going about symbol selection if not by their presence in the literature?
OCTO. said...
- the border between musical and non musical symbols is not clear;
How so?
OCTO. said...
- how will other types of notation be used, such as indian, byzantine? What software?
At this point, who knows. For SMuFL to be a viable standard it needs to be suited for the future needs of software developers.
OCTO. said...
- as an engraver or composer you will perhaps need one symbol that is not found in SMuFL: you can apply for that symbol to SMuFL, if rejected (very possible) you need one font MORE to use in your music, or tweak already existing font;
I'm not sure what you're basing this statement on. If the symbol you're requesting is to be found in any published work, I highly doubt that it will be rejected, since this is basically the sole requirement for inclusion.
OCTO. said...
- The Main Question: why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges? Why cannot f be typed as a keystroke f?
I know that Daniel S is coming from Sibelius where they struggled with symbols spread across many fonts, but this, is in my opinion, as well extreme.
From my perspective as a font designer I can tell you that this is a no brainer, and even as a user of Sibelius, I've found it quite a hassle to deal with numerous different fonts for musical symbols, seemingly without any means of categorization except 'common', 'special' and 'extra special', which isn't very useful at all.
13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3Post Edited (Knut) : 11/9/2016 3:02:49 AM (GMT-6) | | Back to Top | |
|
Knut
Registered Member
Date Joined Jan 2006
Total Posts : 601
| Posted 11/9/2016 7:27 AM (GMT -6) | | Dr. Wiggy said...OCTO. said...
Guess that in 5 years the "New Finale" will support ONLY SMuFL. How will you open your old files if the old Finale is not installable on the current system? 1. It's possible that a SMuFL-compatible Maestro might also be "Maestro-compatible", like November2. 2. Loading a Library that maps the old character glyphs to the new ones should solve most issues. Or perhaps a round-trip through MusicXML. However, there may come a time when backwards compatibility presents such an obstacle to future progress, that a clean break needs to be made with .mus files (as opposed to .musx). As I posted elsewhere, how many other apps can open 20-year old files? Quark XPress can't. InDesign CC can't open PageMaker files. Even ancient Illustrator files may change the text (position, outlining) and other elements on opening.
+1
13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3 | | Back to Top | |
|
Knut
Registered Member
Date Joined Jan 2006
Total Posts : 601
| Posted 11/9/2016 8:13 AM (GMT -6) | | OCTO. said...
OK, I give up! Not because I don't agree with you about SMuFL, but because I do now agree. You have convinced me! :)
Particularly you who work with the music font design - simply I must trust you.
BTW, back to the topic, check MuseScore 2 - really a good software.
Hooray! 
You are a class act, OCTO!
13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3 | | Back to Top | |
|
MikeHalloran
Registered Member
Date Joined Oct 2001
Total Posts : 217
| Posted 11/9/2016 8:54 AM (GMT -6) | | OCTO. said...
...BTW, back to the topic, check MuseScore 2 - really a good software.
Are you kidding?
No real time note entry. Mouse entry is convoluted at best. No video support. PDF export is unwieldy and bloated. MusicXML export and import barely works.
Oh yea, it's free—and worth every penny as far as I'm concerned.
Finale 25.1, 2014.5, 2011c, SmartScore X Pro II, Encore 5.07, GPO 5
2010 iMac i7, 32G RAM, 2T SSD, Late 2013 MacBook Air, OS 10.12.1
MOTU Digital Performer 9.12, 9.02, Logic Pro X 10.2.4 | | Back to Top | |
|
Dr. Wiggy
Early music: modern methods
Date Joined Jun 2006
Total Posts : 12628
| Posted 11/9/2016 1:17 PM (GMT -6) | | tisimst said...OCTO. said...
Why cannot f be typed as a keystroke f? This has long puzzled me as well.
Moving music symbols out of the ASCII range means that a music font could also include a useful text font. This is particularly useful with regard to something like Bravura Text, which is designed to accommodate music symbols within a text environment. (But not actually Bravura Text, which doesn't have ASCII chars.  ) Also, for Unicode compliance, "if it's not the letter A, it shouldn't go in the letter A's slot".
The dynamic letters are only fmrspz. You would either have to make an entire italic face to match these highly stylised forms, or just negate the idea of reserving that range for ASCII symbols.
Furthermore, a decent music notation package should be able to provide easy keyboard entry of high-order Unicode symbols. In Finale, you can program an expression meta-tool to use F for forte and P for piano, if you'd prefer, instead of the number row.
Finale v.25.1, 2012 MacMini; 2012 MacBook Pro (10.11.6 / 10.12.1)
Edirol FA-66; Roland A-49, HP Laserjet 5200 DTN
Ancient Groove Music www.ancientgroove.co.ukPost Edited (Dr. Wiggy) : 11/9/2016 12:20:29 PM (GMT-6) | | Back to Top | |
|
OCTO.
The radical answers.
Date Joined Jul 2008
Total Posts : 2659
| Posted 11/9/2016 2:36 PM (GMT -6) | | tisimst said...Sorry to get back to this, but I thought I'd share a couple of last thoughts OCTO. said...
why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges? Why not? Sure it makes it slightly less convenient to access the glyphs outside of the ASCII range, but that's true for almost every text font as well. So, what have word-processors and the like done?
Well, not completely. Do you have one font that covers roman, italic, semibold, bolditalic, semicondensed......? No.
That was my point. I would simply organize the font family. Clefs, noteheads, flags.... everything is grouped in families.
And than you could have NUMEROUS variants under the flag style, and not limited, you could also expand it by yourself. So when one wants to change a flag, goes to font menu - flag family and choose the symbol. That would be more smart than one large endless font file, with limited flags.
And now, there is Bravura Text. Well...
But I go with SMuFL as it is. I just need to accommodate.
The problem with Sib is not able to add any number of fonts. Also Opus Std doesn't mean so much.
Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM | | Back to Top | |
|
Knut
Registered Member
Date Joined Jan 2006
Total Posts : 601
| Posted 11/9/2016 4:49 PM (GMT -6) | | OCTO. said...tisimst said...Sorry to get back to this, but I thought I'd share a couple of last thoughts OCTO. said...
why do we need only ONE font file to cover all music symbols, and why do we need these Unicode ranges? Why not? Sure it makes it slightly less convenient to access the glyphs outside of the ASCII range, but that's true for almost every text font as well. So, what have word-processors and the like done? Well, not completely. Do you have one font that covers roman, italic, semibold, bolditalic, semicondensed......? No. That was my point. I would simply organize the font family. Clefs, noteheads, flags.... everything is grouped in families. And than you could have NUMEROUS variants under the flag style, and not limited, you could also expand it by yourself. So when one wants to change a flag, goes to font menu - flag family and choose the symbol. That would be more smart than one large endless font file, with limited flags. And now, there is Bravura Text. Well... But I go with SMuFL as it is. I just need to accommodate. The problem with Sib is not able to add any number of fonts. Also Opus Std doesn't mean so much.
I can see your point, OCTO, but I don't think you can compare the concept of separate font styles to separate musical symbol categories. Text font styles like regular, italic and bold are separated into different files because they're stylistically different representations of the same character set. This would not be the case with separating each symbol category into different files, which, in regards to the full scope of SMuFL would result in over 100 different files! Some of these could be easily combined into larger categories, but the number of files you'd have to deal with if you wanted to install a complete SMuFL font would still be very high.
By this principle, if I wanted to create an alternate version of a SMuFL font specifically designed for smaller staff sizes, it would indeed make sense to separate this stylistic alternate version into a dedicated font file, but parsing an entire font into different files by category would be contrary to what most people would expect a font to work. It would be more like separating a text font into upper and lower case latin letters, numerals, latin diacritics, cyrillic letters etc. Very cumbersome indeed.
13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3 | | Back to Top | |
|
Knut
Registered Member
Date Joined Jan 2006
Total Posts : 601
| Posted 11/10/2016 7:44 AM (GMT -6) | | I wouldn't say naive. After all, this isn't necessarily something you have to think about unless you're designing fonts.
Anyway, I totally agree that it can be a drag to deal with a font with a huge number of glyphs, but I think it's better than the alternative, not least for software developers to help improve the situation.
13" MacBook Pro 2.8 Ghz. Intel Core i5, 16 GB RAM, Apogee Duet 2, Samsung SyncMaster 245b
OSX 10.9.5, Finale 2011c and 2014b (not using it yet) w/GPO & JABB, Patterson Plug-Ins, TG-Tools and QuickKeys 4; Sibelius 6, Logic Pro X, Adobe CS3, FontLab Studio 4, FontExplorer X Pro 3 | | Back to Top | |
| 70 posts in this thread.
Viewing Page : 1 2 3 |
| Forum Information | Currently it is Tuesday, December 19, 2023 7:18 PM (GMT -6)
There are a total of 403,820 posts in 58,165 threads.
In the last 3 days there were 0 new threads and 0 reply posts. View Active Threads
|
Forum powered by dotNetBB v2.42EC SP3
dotNetBB © 2000-2023 |
|
|