Finale blog: 27.1

[BuonTempi]

The latest Finale blog claims that version 27.1 is around the corner, and will offer 'substantial value' to users.

https://www.finalemusic.com/blog/the-le ... inale-v27/

Hopefully, this will fix the 'apartheid' between SMuFL and non-SMuFL documents, and have native Apple Silicon builds for both Finale and ARIA, at the very top of any improvements.

[motet]

Like being able to print directly to a printer without the margins getting messed up?

[thomsmit57]

Yeah, that would be of 'substantial value' to me, for sure.

[miker]

More corporate bumpf.

[Michel R E]

"In part 2 of our exciting 3-part series, we will explain to our users why there is an 'N' in the middle of the word 'Finale'. "

[Bill Reed]

Wow, that has just about every corporate cliche there is. "user facing", "carefully crafted". Oy!

[RimasG]

Could someone please explain the advantages of using SMuFL. I am talking about practicalities, not about some "technological advances" that I do not notice in practice. "In Finale the developers emphasise this, but today in v.27 it is more of a headache than a privilege, which I probably don't understand. I expect SMuFL to correlate well with all the others in the future, but why did it have to be presented now, when it's not yet a totally functional option? This is a big problem for those who have their own individual graphic design. For new projects, everything is directed only to the SMuFL mode. This is unfair. This is not free software experimentation. We are honestly paying specific money and we should get a normal product. We hardly need to pay for a beta product.

[miker]

Rimas,

You are absolutely right. Again, Finale is using long-time users as beta testers.

If F27 isn’t working for you, or is working against you, you can always go back to using 26, which is what I have done. But if you must use 27, remember that there is a Legacy document style with the old fonts.

[BuonTempi]

Could someone please explain the advantages of using SMuFL.

In the words of Thomas Morley, "That which you demand requires longer discourse than you look for."

You're right that the current implementation in Finale offers little benefit for the end user at the moment, other than a large range of glyphs that can be accessed from a dialog by content type; and there are several problems that need resolving.

Finale's fonts prior to SMuFL have their origins in the fonts of the 1980s, which could only store up to 255 characters. Finale only adopted Unicode in 2012, I think, allowing it to access the thousands of possible symbols in modern Unicode text fonts. But no music font had taken advantage of Unicode to store thousands of symbols in one font. And Sibelius has its own fonts, whose symbols were not necessarily in the same positions as those used in Finale. And both Sibelius and Finale used several different fonts to contain additional symbols, each mapped to the 8-bit range of characters, instead of putting them all in one font.

There are two main benefits to SMuFL:
Firstly, one single font, containing 1000s of music symbols, all of a matching style, with standardized glyph positions, so that any SMuFL font will work across different apps without needing to change any options. Standardization is a good thing, as it's one less thing to worry about if you can assume it to be true.

Second, and most usefully: it allows the application to "know" that a particular glyph has a particular musical meaning. Up to now, you could make a font for Finale and put the symbols in any character order. F for a breve, & for a fermata, p for forte. But a SMuFL-compliant app or document must have a fermata in a particular glyph position. So the app can then code behaviour specific to that glyph.

As a case in point: Finale is currently 'blind' to the fact that different types of articulation require different treatments. And so we can put a staccato on a rest, because Finale doesn't know whether that articulation is a fermata or a staccato or anything else. A SMuFL-compliant app can know the difference between those two symbols, and change the behaviour accordingly. The glyph is not just a meaningless shape: it is a recognised musical symbol.

(I await the outraged posts providing examples of why staccatos on rests is essential....! )

Of course, until Finale starts making use of this ability, and providing help and functionality more closely tailored to individual notation elements, this is largely academic. However, SMuFL and MusicXML are increasingly linked together, so that XML defines actual notation symbols using SMuFL references.

I believe that Human Playback works in a similar fashion: it assumes the Maestro character slots, and so creates a trill where the Maestro glyph for tr appears in the score. If your font doesn't put tr in the same character slot, then HP won't work.


Tangentially to SMuFL-ness, it's also worth mentioning that all the glyphs in Finale Maestro which were in previous Finale fonts have been revised and improved. Here's Maestro's sfz:

Screenshot 14.png (13.69 KiB) Viewed 9011 times

... and here's the Finale Maestro version:

Screenshot 15.png (13.02 KiB) Viewed 9011 times

[ebiggs1]

Could someone please explain the advantages of using SMuFL.

I can't! I have completed two concert band scores in Finale 27. I see no advantage to me because of smufl fonts. Perhaps there will be in the future but none so far. Again, perhaps, there is some users that benefit from them but I haven't seen it.

I have seen a somewhat big problem because of smufl and I am starting a new thread to 'discuss' it.

[ebiggs1]

Some posters made remarks that MM doesn't read any of these posts. That newest blog suggests they just might be reading them after all.

[Michel R E]

Part 2 of the blog post series has just come out.
Colour me "less than impressed".

[motet]

Continue to color me worried.

[miker]

And rebuttal from the other side of the aisle:

Sharing: Who cares?

SMuFL Support: You screwed it up; you fix it.

Instruments: Most of the people to whom this matters already own extra libraries, and NotePerformer seems to be in the lead.

Platform-specific Usability: In other words, you'll do what you should have been doing all along.

[BuonTempi]

"a list of commonly-reported bugs that we intend to squash" is promising.

Acknowledging the problem is the first step to healing.

[Bill Reed]

How perfect that Part III of the blog is labeled Part I.

So many words; so little information.

[miker]

Amen, Bill.

Remember the days when we could comment on the post?

[Bill Reed]

I remember the days when the "forum" was a group on Compuserve

Well, at least they corrected the title to part III

[whrcomposer]

Why are they still letting Jon Tschiggfrie write these blogs? Does anybody remember the absolute garbage he wrote about the introduction of the sharing features a couple of years ago? If Jon bloviates half as much as this internally when he's supposedly advocating for our needs as users, no wonder the features we're seeing in Finale itself are half-baked, half-finished and only half useful.

I don't know how many thousands of words have gone into those three blog posts, under the most laughable title you can imagine (if "leadership" amounts to vacuous, information-free blather then we're in big trouble), but can anybody point out a single concrete improvement that will be included even in Finale v27.1 after wading through them?

Terrible. Terrible, terrible, terrible. And pity the poor person who has the job of translating that trash into Spanish.

-wr

[Bill Reed]

Not a one

[miker]

And pity the poor person who has the job of translating that trash into Spanish.

He's got it easy: Lo mismo viejo, lo mismo viejo

[SickBoy]

Why are they still letting Jon Tschiggfrie write these blogs? Does anybody remember the absolute garbage he wrote about the introduction of the sharing features a couple of years ago? If Jon bloviates half as much as this internally when he's supposedly advocating for our needs as users, no wonder the features we're seeing in Finale itself are half-baked, half-finished and only half useful.

I don't know how many thousands of words have gone into those three blog posts, under the most laughable title you can imagine (if "leadership" amounts to vacuous, information-free blather then we're in big trouble), but can anybody point out a single concrete improvement that will be included even in Finale v27.1 after wading through them?

Terrible. Terrible, terrible, terrible. And pity the poor person who has the job of translating that trash into Spanish.

-wr

You're awful harsh for someone without an internal perspective on what's going on there. Jon is a fantastic advocate for users and is doing very well given the constraints imposed upon him.

[motet]

I wish he would advocate for fixing bugs over marketing-driven new features that few people want.

[Michel R E]

5 posts, hmmm

[miker]

You're awful harsh for someone without an internal perspective on what's going on there. Jon is a fantastic advocate for users and is doing very well given the constraints imposed upon him.

And your source for this is...?