|
|
| MakeMusic Forum > Public Forums > Finale - Macintosh - FORUM HAS MOVED! > Finale 2014 is a nightmare. Most disappointing update in a long time | Forum Quick Jump
|
 |
rpmseattle
Registered Member
      
Date Joined Nov 2006
Total Posts : 419
| Posted 11/24/2013 4:58 PM (GMT -6) |   | saxop said...
I don't find Finale's quality to be significantly different from other content development applications I use. I believe the Finale team is both smart and dedicated, and I don't think that any of us would do a better job. This forum makes us aware of a lot more problems than we would know about if we each used the program in isolation, and that's affecting perception. I doubt the general consensus matches.
While I don't argue that the Finale team is qualified, I'm surprised to hear that you think Finale's quality control is what you experience with other software, actually, unless you are perhaps comparing MakeMusic to Microsoft, which for a long time had a history of rolling out software before it was fully baked.
The Finale team can be both smart and dedicated, and still require a more effective and systematic approach for finding and eradicating bugs in the software than it has now, as well as its "UI-think". With the professional level users I know, the only ones I hear saying Finale is "great" and "awesome" without adding some sort of caveat are people giving soundbites for MakeMusic's press releases. That is to say, we initially talk about how wonderful the new keyless instrument feature is, but the discussions following that are more about what didn't get cleaned up. Every version.
You imply that it takes special skill to be a programmer. Absolutely, but I'm not a programmer; I'm a pro level end user. I don't *care* how everything works under the hood, or how hard something specific is to fix, change or create (although I appreciate the amount of work that is required to build a well-designed and stable new release). What I do know is that I use the program every working day, and I can see where Finale's competitors are, and what their level of quality control is, and how intuitive (or not) their UI's are. And I use more than one notation program, so I *know* what I'm missing currently in Finale. The fact that I can export Finale files into a competitor's program via Music XML should be the *last* think I consider for each job, not the first.
Perhaps you are a Finale beta tester; my intent is not to offend you or anyone; it's to lobby for more stable releases of the software with a more consistent UI. New features are great, and consistently are higher on the "wow" scale which translates to sales, but I use the software every working day. To me, little bugs or a UI niggle that has been subtly interrupting my workflow on a daily basis until I'm trained to put up with it, or to turn it off because it breaks under my workflow are important enough for MakeMusic to fix, IMO.
I don't know the exact method that MakeMusic uses to prioritize whether or not resources are thrown toward something, but I believe good product development should be more than just assigning a statistical value to a report of a bug; e.g. how many times it gets reported. There are many Finale users who will never even use certain features of the program. Professional users of the program are in a position to provide excellent feedback to MakeMusic; they shouldn't be penalized because their numbers don't represent a significant lobbying force (if prioritizing what gets fixed is purely by user statistics).
I would agree that by sharing findings on this forum, we are at least aware of issues we need to avoid. But I would argue that a better scenario would be for the forum to be primarily about users helping other users; where understanding of how a well designed and bug free feature works is the biggest obstacle to overcome.
Robert Puff
Finale 2012, 2011 | Mac Pro 8 Core Xeon | OSX 10.6.x
www.musicprep.com/makemusic
www.rpmseattle.com/of_note/category/finale/Post Edited (rpmseattle) : 11/24/2013 4:05:11 PM (GMT-6) | | Back to Top | |
|
saxop
Registered Member
Date Joined Mar 2007
Total Posts : 261
| Posted 11/24/2013 5:41 PM (GMT -6) | | rpmseattle said...
While I don't argue that the Finale team is qualified, I'm surprised to hear that you think Finale's quality control is what you experience with other software, actually, unless you are perhaps comparing MakeMusic to Microsoft, which for a long time had a history of rolling out software before it was fully baked.
No, I wasn't talking about large companies. But let's not pretend that Finale 2014 is anything close to the PR disaster that Apple had on its hands when it rolled out its maps replacement. I mean, Apple actually had to recommend its competitors' products.  And then of course there is HealthCare.gov...
I encounter occasional crashes with a lot of software I use, mostly programming IDEs and audio/art creation tools. Finale is more stable than the majority of those, so I give them credit. I also can't really say that I ever have to ask questions about how to achieve something with it or that any bugs are impossible for me to work around. For my particular needs, Sibelius' bugs and shortcomings are much more inconvenient, so Finale is definitely better for me. | | Back to Top | |
|
Writer of Music
Registered Member
Date Joined Aug 2011
Total Posts : 848
| Posted 11/24/2013 7:00 PM (GMT -6) | | Wiggy said...
I have Tamburo active on my system with no problem. Are you saying that you've reinstalled the font from MM with each new version and have problems?
Since Tamburo was always found to be corrupted (by FontBook, FontDoctor, Suitcase, etc.), I always removed it after installation, which means that it will get reinstalled with every upgrade/update. I have no use for Tamburo, so I'll remove it again. If I remember well, Seville was another problematic font, but I never had any use for that one either.
Finale 2014, but switched back to 2012c
Mac OS X 10.9, 2.66 GHz Intel Core 2 Duo, 8 GB 1067 MHz DDR3
… as the critic said to the composer: "It's not just you're a brownnose, your music really stinks". | | Back to Top | |
|
rpmseattle
Registered Member
Date Joined Nov 2006
Total Posts : 419
| Posted 11/24/2013 8:03 PM (GMT -6) | | Motet said...
What's really wanted are beta testers that are willing to use the new version for actual work--that's the way real testing and regression testing are going to happen.
I would agree with that.
I run into bugs in 100+ bar orchestral scores that frankly, would never show up in a virgin 32 bar lead sheet.
Another issue is that it or not, users continue to update old files to create new templates, which makes it harder for Finale to effectively find and fix bugs. Finale users typically feel it's far too labor intensive to build a pro level template from scratch for each new version (it shouldn't be).
For instance, Finale hasn't made it easy to import Category settings (new categories are always added with Expression Libraries even if the Category name is identical). There is no Category Designer Library item specifically, so one must update the fonts and placement of each item in each category manually. Furthermore, a number of Document Settings do not update immediately when you import a house style, so for instance, one must go into each staff to change the font, size and style of individual instrument names, rather than being able to do this globally as part of the Import House Style.
This makes it extremely labor intensive to build a new template from scratch, because so many things have to be set manually. User's templates get messier with each new update because it's so labor intensive to build a new template from the ground up. Some basic house style housekeeping improvements to Finale that reduced the need to rely on old files would really make a positive difference.
Additionally, it is my opinion that the beta program itself needs some kind of systematic overhaul - obvious things are currently not being caught, and the vanilla release of each version of Finale is historically buggy.
Concurrent with that, there needs to be someone at the helm who really understands good design UI. Someone needs to make more user friendly and efficient UI decisions than what is currently implemented. In fairness, we are seeing lots of improvements. Nevertheless...
A very basic improvement would be reducing the number of keystrokes and mouse clicks for any and all operations where this is possible to do so. An example of this would be showing text in the part which is hidden in the score. Current steps are (1) right click (2) select Unlink in Part (3) Hide in score. Easier would be " Show in Score", "Show in Part" and "Show in All" contextual menu items. Any of these choices represents a single operation.
Finally, when something like the above is implemented for one object, follow through and add this functionality for other similar objects. If history is any indication, we would see the above implemented for expressions but not for hairpins. Which means that whoever has been at the helm has not been aware of the larger workflow picture, IMO.
Robert Puff
Finale 2012, 2011 | Mac Pro 8 Core Xeon | OSX 10.6.x
www.musicprep.com/makemusic
www.rpmseattle.com/of_note/category/finale/Post Edited (rpmseattle) : 11/24/2013 7:15:04 PM (GMT-6) | | Back to Top | |
|
rpmseattle
Registered Member
Date Joined Nov 2006
Total Posts : 419
| Posted 11/24/2013 11:31 PM (GMT -6) | | Christopher Smith said...
You can do this for every staff at once, or for a set of staves, using the Global Staff Attributes plugin.
Yes, thanks for the reminder, Chris. And in the spirit of completeness, this works for Group Attributes, too, (although the Global Staff Attributes plugin is still a secondary, discreet step from importing the Document Options / House Style). Of course, the main point of my post was that updating a virgin Finale file to incorporate all of a users settings and house style is currently an enormous amount of work, which encourages users to keep updating old template files, which are more prone to issues in the first place.
For instance, if you open an old Finale file in a new version, delete a few staves and then added some new ones, it's interesting to note that Finale retains the old deleted staff numbers somewhere in the file, and that the new staves which are added are numbered as if the deleted staves still existed. This might be an explanation for why, when new staves are added in a large score, sometimes Chord Symbols or staff attached text will appear along with the new staff. Definitely a reproducible bug in an old file with a lot of staves, but not one that will be reproducible in a virgin document, because the staff number assignments haven't become messed up.
Making a greater number of the internal Document Options and other house style settings available to save and load as part of a master house style, so a new score can be updated in real time, and more users will be encouraged to work smarter, in new files that are leaner, and less prone to bugs.
Robert
Finale 2012, 2011 | Mac Pro 8 Core Xeon | OSX 10.6.x
www.musicprep.com/makemusic
www.rpmseattle.com/of_note/category/finale/Post Edited (rpmseattle) : 11/24/2013 10:46:49 PM (GMT-6) | | Back to Top | |
|
saxop
Registered Member
Date Joined Mar 2007
Total Posts : 261
| Posted 11/25/2013 12:37 AM (GMT -6) | | rpmseattle said...saxop said...
That design would confuse users some, since it wouldn't be clear that movement was also unlinked by the change in visibility. In this particular case, the critical action is user control of visibility. The fact that Finale needs to "unlink" the text in order to hide in one view separately from the other is a technical programming consideration which IMO should be kept under the hood. There is no menu selection or label required when you *move* text in a part; it is understood that by moving the text, you are unlinking it from the score. The indicator that tells you is a color change. If you select a text object and select "Show In Parts", and the text object becomes color coded in the part and grayed out in the score, the meaning would be very clear, and the action would be a single step rather than 3.
No, I'm afraid I can't agree that design would be better. It's not just a technical programming detail, it's a design intention that I think is preferable. I don't want two separate types of linking, one controlling visibility and another controlling position. It's simpler for the user if unlinked means unlinked, and the color difference serves to alert the user that both visibility and position may differ between the parts and score. Having separate commands for show in part/score/all would also become a problem when an object is shown/hidden in multiple parts but not all of them. There are more than three potential visibility states for an object. | | Back to Top | |
|
Jari Williamsson
Registered Member
 
Date Joined Dec 1998
Total Posts : 3246
| Posted 11/25/2013 2:23 AM (GMT -6) | | rpmseattle said...
Easier would be " Show in Score", "Show in Part" and "Show in All" contextual menu items. Any of these choices represents a single operation.
What if things should show in all grand staff parts but not anywhere else? Or in the score and the piano part only? Or just in the percussion or string parts?
rpmseattle said...
Yes, thanks for the reminder, Chris. And in the spirit of completeness, this works for Group Attributes, too, (although the Global Staff Attributes plugin is still a secondary, discreet step from importing the Document Options / House Style). Of course, the main point of my post was that updating a virgin Finale file to incorporate all of a users settings and house style is currently an enormous amount of work, which encourages users to keep updating old template files, which are more prone to issues in the first place.
IMO, the Document Options is not the house style. A house style is the part of the "look" that never changes, regardless of which kind of piece that is notated. There are Document Options that should not be change in a house style change. And there are elements that are not controlled by settings that are part of the house style. I agree that a house style change should be one step, but it should go deeper and more selectively than just some predefined settings. I'll try to prepare a demo video for you.
Jari Williamsson
Windows XP, Pentium 4
2.40 GHz, 4 GB RAM
www.finaletips.nu - The Finale Productivity Tips site | | Back to Top | |
|
Jari Williamsson
Registered Member
Date Joined Dec 1998
Total Posts : 3246
| Posted 11/25/2013 5:26 PM (GMT -6) | | rpmseattle said...
What Document Options do you believe should not be changed as part of a House Style description?
From a quick scan, I'd personally not want these in a house style: The layer options, Use cross-layer accidental positioning, some of the Close barlines options, Punctuation to Ignore, some of the Beams options, how time signatures are abbreviated and how key/time courtesy sigs are displayed. Everything that are connected to the specific musical contents rather than the look of the document should be excluded from a house style IMO.
I also want to clarify that apart from settings and libraries, a house style should include other things that are part of a style sheet but not part of any settings: how hairpins ends on long notes, distance between dynamics and hairpins, how hairpins ends before rests, if dynamics are fully or partially aligned below/above a staff, if angled hairpins are allowed or not, etc, etc. A house style "action" should create as good starting point as possible towards the style sheet. In one step. I'm soon there.
Jari Williamsson
Windows XP, Pentium 4
2.40 GHz, 4 GB RAM
www.finaletips.nu - The Finale Productivity Tips site | | Back to Top | |
|
Writer of Music
Registered Member
Date Joined Aug 2011
Total Posts : 848
| Posted 11/27/2013 6:33 AM (GMT -6) | | Michael Mortilla said...Mike Rosen said...
WoM,
You and Marc are gonna be mighty lonely... All work and no play. No sense of dealing with actual humans or that reading into the humor and o/t comments might provide some insight. No reading innuendo. No idea of subtext. No camaraderie or sense of a larger community with different perspectives than themselves. In short: not a clue. What a dull existence to even contemplate. It always the very same set of members who, coincidentally, seem to be the ones with the one-off problems unique to their systems or "rare and unique" problems needing to be solved. It would be funny if it weren't so pathetic. Yes, the blocking feature is very helpful, indeed.
Mr. Mortilla, I'm still waiting for apologies. If you're man enough to insult someone publicly, you should also be man enough to publicly offer apologies.
Finale 2014, but switched back to 2012c
Mac OS X 10.9, 2.66 GHz Intel Core 2 Duo, 8 GB 1067 MHz DDR3
… as the critic said to the composer: "It's not just you're a brownnose, your music really stinks".Post Edited (Writer of Music) : 11/29/2013 5:19:40 PM (GMT-6) | | Back to Top | |
|
Bret Boulon
Registered Member
Date Joined Jan 2003
Total Posts : 106
| Posted 11/28/2013 4:53 AM (GMT -6) | | Hate 2014 so far; buggy and slow beyond hope.
Hated 2012.
back working with 2011 ,and I think I will never buy any upgrade from mm again (until my machine can work)
People, go back to fundamentals : music notation and modernisation of finale 1.0 areas.
Bret | | Back to Top | |
|
Writer of Music
Registered Member
Date Joined Aug 2011
Total Posts : 848
| Posted 11/28/2013 8:29 AM (GMT -6) | | As far as I have tested 2014 it was faster than 2012 in most areas. The score manager of 2014, however, was horrifically slow on my system.
And, speaking of the score manager, the same 2012 score manager bug existed in 2014: any change in score setup results in instrument groups changes or even disappearances as well as staff attributes changes, which for me more or less defied the entire benefit of the score manager. 2014 being as slow as it is (score manager wise) turned the score manager into a nuisance, rather than a useful tool.
Other's mileage varying, of course.
Finale 2014, but switched back to 2012c
Mac OS X 10.9, 2.66 GHz Intel Core 2 Duo, 8 GB 1067 MHz DDR3
… as the critic said to the composer: "It's not just you're a brownnose, your music really stinks". | | Back to Top | |
|
Writer of Music
Registered Member
Date Joined Aug 2011
Total Posts : 848
| Posted 11/30/2013 4:17 PM (GMT -6) | | No, I'm actually speaking of the nasty habit to spontaneously change staff groups and staff attributes, whenever one adds or deletes an instrument in the score manager — which it was intended for in the first place. E.g., when I add, say, a percussion line, the woodwind grouping afterwards extends to the 2nd horn, two extra, empty groups have been created and the grouping of the divisi violin I is gone altogether; violin I is now incorporated into the grouping of the divisi violin II. Additionally, many more instruments suddenly show measure numbers, when neither the score list nor the staff attributes settings allowed them to show these.
I understand that it is not really an issue for typesetters, but I dread every change I need to make in the instrumentation, because it means I will need to spend yet again quite some time on repairing groupings and staff attributes. As useful as the score manager otherwise is, this is a serious bug to me. Add the horrendous inertia of the same in Finale 2014 and I ran into one more reason to give up on 2014, at least until the next update.
Finale 2014, but switched back to 2012c
Mac OS X 10.9, 2.66 GHz Intel Core 2 Duo, 8 GB 1067 MHz DDR3
… as the critic said to the composer: "It's not just you're a brownnose, your music really stinks".Post Edited (Writer of Music) : 11/30/2013 3:21:00 PM (GMT-6) | | Back to Top | |
| 165 posts in this thread.
Viewing Page : 1 2 3 4 5 6 7 |
| Forum Information | Currently it is Tuesday, December 19, 2023 7:00 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 |
|
|