Finale SmartMusic
  Home | Log In | Register | Search | Help
   
MakeMusic Forum > Public Forums > Finale - Macintosh - FORUM HAS MOVED! > The new notation program?  Forum Quick Jump
 
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
70 posts in this thread.
Viewing Page :
 1  2  3 
[ << Previous Thread | Next Thread >> | Show Oldest Post First ]

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/10/2016 7:44 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 9:43 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Hm.. I understand you Knut. And trusts you as well. :)
My knowledge about fontt "engines" is limited, and I am perhaps a bit naive in my ideas.... :(




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 4:49 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 2:36 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Dr. Wiggy
Early music: modern methods



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Dr. WiggyAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 2006
Total Posts : 12628
 
   Posted 11/9/2016 1:17 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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. :p) 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.uk

Post Edited (Dr. Wiggy) : 11/9/2016 12:20:29 PM (GMT-6)

Back to Top

tisimst
Registered Member



Email Address Not AvailableClick to visit tisimst's website.Send a Private Message to tisimstAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2015
Total Posts : 18
 
   Posted 11/9/2016 12:00 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Sorry to get back to this, but I thought I'd share a couple of last thoughts...

OCTO. said...
- repetitive symbols found over again;

Part of this is compliance with Unicode itself. There are a few locations within Unicode where musical symbols are already expected to be. So, SMuFL (or rather, Bravura) copies glyphs to those code points as well in case someone is using those to access music symbols.

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? They've created ways to make accessing the glyphs easier for users. I'd much rather have everything in a single file. It's much easier to manage (at least for me).

OCTO. said...
Why cannot f be typed as a keystroke f?

This has long puzzled me as well. Good news is, it's not hard for font designers to do (and maybe *should* do) and makes a lot of sense to me to at least have a copy of the dynamic letters also available in the normal ASCII code points.


Music Typeface Designer & Engraver - LilyPond | Sibelius | Finale | Dorico | SMuFL | Inkscape | FontForge
leighverlag.blogspot.com | www.musictypefoundry.com

Back to Top

Vaughan
Registered Member

Click to send Vaughan email.Personal Homepage Not AvailableSend a Private Message to VaughanAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 1999
Total Posts : 4984
 
   Posted 11/9/2016 10:27 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
I had fleeting experience with MuseScore v2 because a colleague did a rather large project using it. While I appreciate the open source aspect of it, as well as certain aspects of its interface and the willingness of the makers to listen to and give assistance to users, it wasn't even close to being able to produce consistently professional results. Having said that, they're working hard on v3 which is supposed to have a large number of improvements and refinements, like an equivalent to Sibelius' magnetic spacing. It's about time Finale had something similar and it would surprise me if MM weren't working on it.


Vaughan

Finale 3.2 - 25, Sibelius 4 - 7
Patterson's plugins, Tobias' plugins, full version, waiting for Jari's plugin update
MacOS 10.12
MacPro (2016) 16 GB, MacBookPro (2011) 8 GB

Amsterdam

Back to Top

MikeHalloran
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to MikeHalloranAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Oct 2001
Total Posts : 217
 
   Posted 11/9/2016 8:54 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 8:13 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 8:08 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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.




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 7:27 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Dr. Wiggy
Early music: modern methods



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Dr. WiggyAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 2006
Total Posts : 12628
 
   Posted 11/9/2016 6:59 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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.


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.uk

Post Edited (Dr. Wiggy) : 11/9/2016 6:02:26 AM (GMT-6)

Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 6:28 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Knut said...
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.

...Not being able to reply to all other, this is very relevant. 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?




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Post Edited (OCTO.) : 11/9/2016 5:31:15 AM (GMT-6)

Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/9/2016 3:57 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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 3

Post Edited (Knut) : 11/9/2016 3:02:49 AM (GMT-6)

Back to Top

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/9/2016 12:20 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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 RAM

Post Edited (OCTO.) : 11/9/2016 12:34:29 AM (GMT-6)

Back to Top

tisimst
Registered Member



Email Address Not AvailableClick to visit tisimst's website.Send a Private Message to tisimstAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Feb 2015
Total Posts : 18
 
   Posted 11/8/2016 12:56 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
+++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

Robert P.
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Robert P.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Apr 2004
Total Posts : 1691
 
   Posted 11/8/2016 5:55 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
++1
Back to Top

Knut
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to KnutAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2006
Total Posts : 601
 
   Posted 11/8/2016 3:59 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

OCTO.
The radical answers.



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to OCTO.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jul 2008
Total Posts : 2659
 
   Posted 11/8/2016 1:38 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
As Wiggy described somewhere, it is possible to have Maestro SMuFL-compatible AND to have it working for old files. The question is if MM or Avid want to make their property fonts SMuFL compatible. I don't think they want. Personally I have very mixed feeling for SMuFL.

BTW, no one is talking about MuseScore 2 and v3. It has more features than Dorico and many other features that I would like to see implemented in Finale. It is a greatly designed software.




Finale 2014.5 • OS X: Yosemite, MPB 15', 16GB RAM

Back to Top

N. Grossingink
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to N. GrossinginkAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2002
Total Posts : 3991
 
   Posted 11/7/2016 12:50 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Thanks, John.

I hope users that use other fonts are prepared for the switchover to SMuFL. I would save a "Maestro Font Default" that is un-SMuFLized and a number of template formats with the current font mapping. Otherwise, your 3rd party font aint gonna work anymore on the new setup.

N.


OSX El Capitan 10.11.6
Finale 2011c, 2012c for production work

Finale 2014.5, not used by my clients

(Finale v25 - not interested yet)

TgTools, Patterson Plugins, JW Change and Staff Polyphony, QuicKeys 4
Mac Mini 2.4 Ghz Intel, 8GB RAM
New Belgium Fat Tire Ale

Back to Top

John Ruggero
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to John RuggeroAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2000
Total Posts : 820
 
   Posted 11/7/2016 11:31 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
N. Grossingink said...
when will Maestro become SMuFL compliant


I asked this question on this forum and received the following response:

forum.makemusic.com/default.aspx?f=6&m=483981

I much prefer the Maestro Font to Bravura and would not switch to Dorico on that basis alone. Bravura is, however, a useful repository of symbols not available in Maestro, and in some cases has for me better versions of certain characters, like the tremolo slashes, for example.

Jetcopy said...
The automation is what I have always disliked about Sibelius. When using Sibelius, I felt as if the programmers thought the program was "smarter" than the user and the program knew what was best.


+1


Mac mini (OS 10.8.5) with dual monitors, Finale 2014d (Finale 2011 as a backup) with GPO 4
Kurzweil Mark 5 with M-Audio Midisport 2 x 2, Adobe InDesign CS4 SmartScore X Pro, JW Plug-ins
www.cantilenapress.com

The better the composer, the better the notation.

Back to Top

John Ruggero
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to John RuggeroAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2000
Total Posts : 820
 
   Posted 11/7/2016 11:17 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Michel said...
The designers/creators of Dorito seem to be very proud of the fact tat they designed the program to be used on a laptop.
I don't understand how this is any sort of "plus" for the program.


Haven't you heard that desktop computers are now obsolete and multiple and large monitors are passé? Who needs all that screen real estate and the ability to select and move things around with a mouse? Laptops bring back the glorious days of typewriters and word processors and are the future! Soon the only Mac will be a MacBook.

I also disagree that one should spend any time away from electronic devices. How can one enjoy the beauty of the glorious Fall day we are having today unless one is staring at some sort of electronic screen? ;-)


Mac mini (OS 10.8.5) with dual monitors, Finale 2014d (Finale 2011 as a backup) with GPO 4
Kurzweil Mark 5 with M-Audio Midisport 2 x 2, Adobe InDesign CS4 SmartScore X Pro, JW Plug-ins
www.cantilenapress.com

The better the composer, the better the notation.

Post Edited (John Ruggero) : 11/7/2016 10:21:42 AM (GMT-6)

Back to Top

N. Grossingink
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to N. GrossinginkAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2002
Total Posts : 3991
 
   Posted 11/7/2016 11:17 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Another thing to remember about Dorico is that the music font must be SMuFL compliant. That's likely to be a big/impossible hurdle for publishers and individuals who favor a custom or 3rd party font. The font designed for Dorico, Bravura, is indeed a very classy font and should satisfy most.

Speaking of SMuFL, I've been given to believe that Make Music is somehow associated with the organization that has pioneered this particular standard. That begs the question, when will Maestro become SMuFL compliant, and how incomplete or screwed up will its first appearance be?

N.


OSX El Capitan 10.11.6
Finale 2011c, 2012c for production work

Finale 2014.5, not used by my clients

(Finale v25 - not interested yet)

TgTools, Patterson Plugins, JW Change and Staff Polyphony, QuicKeys 4
Mac Mini 2.4 Ghz Intel, 8GB RAM
New Belgium Fat Tire Ale

Back to Top

Michel R. E.
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Michel R. E.AIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined May 2003
Total Posts : 7430
 
   Posted 11/7/2016 10:44 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Mike Halloran said...
John Ruggero said...
...And even if this were fixed, I would never use a program that uses number input for tasks that are better suited to a mouse. It is too unpleasant and inefficient....


Ahhhh... handicapped users will be unable to use it. Thanks for the heads up.

No reason for me to waste any more time on Dorico. That includes reading about it.


The designers/creators of Dorito seem to be very proud of the fact tat they designed the program to be used on a laptop.
I don't understand how this is any sort of "plus" for the program.

I understand that it should WORK on a laptop, but to emphasize that it is actually designed specifically with a laptop in mind seems counter-intuitive.

I think the vast majority of users won't be "on the move" when working on their music. maybe I'm wrong, but then I'm not a jet-setting musician spending all my free time in airports and on buses going from concert premiere to concert premiere.
The times I HAVE travelled for a premiere I honestly couldn't give a crap about working on more music. I was happy to be a silly tourist and snap pictures of nothing through my airplane window.


Finale (started with ver. 3.0) using 2012 (2014 has been shelved for its lack of support for older Garritan libraries), putting Finale 25 through its paces.
Windows 8.1
basically ALL Garritan libraries, plus XSample Chamber Ensemble.

"Art critics suffer from Pigeon Syndrome. Pigeons like to leave their mark on monuments. But at the end of the day, the pigeon remains a pigeon, and the monument remains a monument."

Back to Top

Mike Halloran
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Mike HalloranAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jun 2009
Total Posts : 105
 
   Posted 11/7/2016 10:38 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
John Ruggero said...
...And even if this were fixed, I would never use a program that uses number input for tasks that are better suited to a mouse. It is too unpleasant and inefficient....


Ahhhh... handicapped users will be unable to use it. Thanks for the heads up.

No reason for me to waste any more time on Dorico. That includes reading about it.


Mike Halloran

Finale 25.1 & 2014.5, SmartScore X Pro II, Encore 5.0.7
2010 iMac 2.93G i7 Quad w/ OWC eSATA mod, 20G RAM, OS 10.12.1, 2T SSD
DP 9.1, 8.07, 7.24, Logic Pro X 10.2.4, DSP-Quattro, PSP, IK, NI, Eventide, Izotope & Antares plugins
G4 running OS 10.4.11 & 9.2 with legacy apps

Back to Top
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
70 posts in this thread.
Viewing Page :
 1  2  3 
   
Forum Information
Currently it is Saturday, December 5, 2020 3:49 AM (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