Finale SmartMusic
  Home | Log In | Register | Search | Help
   
MakeMusic Forum > Public Forums > Finale - Macintosh - FORUM HAS MOVED! > Finale 2014 is a nightmare. Most disappointing update in a long time  Forum Quick Jump
 
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
165 posts in this thread.
Viewing Page :
 1  2  3  4  5  6  7 
[ << Previous Thread | Next Thread >> | Show Newest Post First ]

Writer of Music
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Writer of MusicAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Aug 2011
Total Posts : 848
 
   Posted 11/24/2013 11:04 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Wiggy said...
Christopher Smith said...
From what has been said on the forums here and my own experiences, Finale <sometimes> gets its font knickers in a twist when it installs. I've never had to re-empty the font cache again in the general running of Finale. Your experience is unusual and I would suggest possibly being caused by something else.


I have been getting font id conflicts and a corrupt Tamburo font for as long as I have software to analyse fonts and font issues (must have somewhere in the 1990s). I have had many changes of hardware (cq. clean installs) since and many an upgrade/update from Finale (cq. clean installs), but always the same issues. Cleaning the cache solves nothing in this case — but given the clean installs, these issues could or even should be present on just about everyone's system.


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

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/24/2013 11:21 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Writer of Music said...
I have been getting font id conflicts and a corrupt Tamburo font for as long as I have software to analyse fonts and font issues (must have somewhere in the 1990s). I have had many changes of hardware (cq. clean installs) since and many an upgrade/update from Finale (cq. clean installs), but always the same issues. Cleaning the cache solves nothing in this case — but given the clean installs, these issues could or even should be present on just about everyone's system.

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?

Christopher Smith said...
What's wrong with 2010 on 10.4? ..... Mac iBook G4 733 Mhz

I can't find a 733MHz G4 iBook on Mactracker. The first G4 iBook have 800MHz CPUs, so all of them should run 10.5. While 10.4 is within the minimum requirements for Finale 2010, it's a 2005-vintage OS. 2010 was designed to run on 10.5 (and released just before 10.6 came out smilewinkgrin ) I would upgrade to 10.5 if you can: the benefits are immeasurable.


"This is me helping."

Finale 2014, 2.6Ghz 2012 MacMini 16Gb RAM (10.9); 2009 MacBook
Edirol FA-66; M-Audio Oxygen 61; Yamaha PSR-410, HP Laserjet 5200 DTN
Ancient Groove Music www.ancientgroove.co.uk

Back to Top

rpmseattle
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to rpmseattleAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2006
Total Posts : 419
 
   Posted 11/24/2013 1:22 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Motet said...
not everything is methodically tested. Going through all the plug-ins and keyboard shortcuts documented in the manual would have taken someone at most one day.


I strongly agree on this point. There needs to be a (better and different) systematic approach to in-house testing, logging and tracking bugs and external beta testing. Historically, not only are new bugs introduced with new features (a certain small amount of this is statistically inevitable) but also old bugs are brought forward into new versions at an unacceptable rate.

The current Quality Control approach, systematic or not, obviously isn't working successfully; in fact, compared to other similar software might be considered an Epic Fail. Solution is clear: (a) Isolate ineffective processes and figure out why the current Quality Control arm is not producing a much higher rate of bug-free software and implement changes so that MakeMusic's software releases are consistently more bug-free and perhaps concurrently with that (b) HR needs to isolate ineffective employees and replace them with people who are more skillful with the particular and very important position of Quality Control. Let's hope that this latest round of corporate reorganization will address both of these things.


Finale 2012, 2011 | Mac Pro 8 Core Xeon | OSX 10.6.x
www.musicprep.com/makemusic
www.rpmseattle.com/of_note/category/finale/

Back to Top

saxop
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to saxopAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2007
Total Posts : 261
 
   Posted 11/24/2013 3:45 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
rpmseattle said...
Motet said...
not everything is methodically tested. Going through all the plug-ins and keyboard shortcuts documented in the manual would have taken someone at most one day.


I strongly agree on this point. There needs to be a (better and different) systematic approach to in-house testing, logging and tracking bugs and external beta testing. Historically, not only are new bugs introduced with new features (a certain small amount of this is statistically inevitable) but also old bugs are brought forward into new versions at an unacceptable rate.

The current Quality Control approach, systematic or not, obviously isn't working successfully; in fact, compared to other similar software might be considered an Epic Fail. Solution is clear: (a) Isolate ineffective processes and figure out why the current Quality Control arm is not producing a much higher rate of bug-free software and implement changes so that MakeMusic's software releases are consistently more bug-free and perhaps concurrently with that (b) HR needs to isolate ineffective employees and replace them with people who are more skillful with the particular and very important position of Quality Control. Let's hope that this latest round of corporate reorganization will address both of these things.


It's easy to complain about the job others are doing until we try to do it ourselves. 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.
Back to Top

rpmseattle
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to rpmseattleAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2006
Total Posts : 419
 
   Posted 11/24/2013 4:58 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Motet
Isorhythmic



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to MotetAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 2002
Total Posts : 12849
 
   Posted 11/24/2013 11:27 PM (GMT 0)    Quote This PostAlert An Admin About This Post.
What I don't quite understand is why beta testing doesn't catch the obvious problems that always turn up on day one of a new release. Are the beta testers only trying the new features to make sure they work? It's likely the developers have already done that, so it's not terribly useful. 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.

And my just-quoted suggestion that plug-ins and keyboard shortcuts be tested is obviously not being done.


Finale 2011b, 2005, TGTools
Windows XP

Back to Top

saxop
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to saxopAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2007
Total Posts : 261
 
   Posted 11/24/2013 5:41 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Writer of MusicAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Aug 2011
Total Posts : 848
 
   Posted 11/24/2013 7:00 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to rpmseattleAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2006
Total Posts : 419
 
   Posted 11/24/2013 8:03 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Christopher Smith
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Christopher SmithAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Sep 2007
Total Posts : 2290
 
   Posted 11/24/2013 9:41 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
rpmseattle said...
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.

Robert Puff


You can do this for every staff at once, or for a set of staves, using the Global Staff Attributes plugin.

But I see your point that this should be importable.


Christopher Smith

Mac 2 x 2 Ghz Dual-Core Intel Xeon
OSX 10.6.8
Finale 2011b and 2012c r.13
or
Mac iBook G4 733 Mhz
OSX 10.4.11
Finale 2010b r.1

Back to Top

rpmseattle
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to rpmseattleAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2006
Total Posts : 419
 
   Posted 11/24/2013 11:31 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to saxopAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2007
Total Posts : 261
 
   Posted 11/24/2013 11:39 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
rpmseattle said...
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.


That design would confuse users some, since it wouldn't be clear that movement was also unlinked by the change in visibility. Since the critical action that's taking place really does involve linking/unlinking, it's probably clearest to make the commands reflect that. The show/hide action is really separate, like movement, and only relates to linking in that its effect varies based on whether the link exists.
Back to Top

rpmseattle
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to rpmseattleAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2006
Total Posts : 419
 
   Posted 11/24/2013 11:57 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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.


Finale 2012, 2011 | Mac Pro 8 Core Xeon | OSX 10.6.x
www.musicprep.com/makemusic
www.rpmseattle.com/of_note/category/finale/

Back to Top

saxop
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to saxopAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Mar 2007
Total Posts : 261
 
   Posted 11/25/2013 12:37 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Click to send Jari Williamsson email.Click to visit Jari Williamsson's website.Send a Private Message to Jari WilliamssonAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 1998
Total Posts : 3246
 
   Posted 11/25/2013 2:23 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

rpmseattle
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to rpmseattleAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2006
Total Posts : 419
 
   Posted 11/25/2013 4:31 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Jari Williamsson said...
There are Document Options that should not 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 would agree completely that more configurability is desirable. As an example, Finale currently has 18 discreet Library items. But that list could be expanded upon; for instance, the Category Designer settings mentioned earlier could ideally be a library item.

Fonts are currently a multi-step process to update properly in a document. The Category Designer handles the fonts for expressions, which are most typically related to the various font choices for text in the Document Options (a font "family" is used as part of a House Style), but it is several steps to update the related fonts of Page text, measure numbers, articulations etc. currently, using different tools and dialogs.

What Document Options do you believe should not be changed as part of a House Style description?


Finale 2012, 2011 | Mac Pro 8 Core Xeon | OSX 10.6.x
www.musicprep.com/makemusic
www.rpmseattle.com/of_note/category/finale/

Back to Top

Jari Williamsson
Registered Member

Click to send Jari Williamsson email.Click to visit Jari Williamsson's website.Send a Private Message to Jari WilliamssonAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 1998
Total Posts : 3246
 
   Posted 11/25/2013 5:26 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Writer of MusicAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Aug 2011
Total Posts : 848
 
   Posted 11/27/2013 6:33 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Bret BoulonAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Jan 2003
Total Posts : 106
 
   Posted 11/28/2013 4:53 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

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/28/2013 7:03 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Bret Boulon said...
Hate 2014 so far; buggy and slow beyond hope.

Most impressions of it are that it is significantly faster and more responsive than previous versions. That's certainly been my experience. Perhaps this slowness on your computer can be sorted out?

Bret Boulon said...
Hated 2012.

Any particular reason?

Bret Boulon said...
back working with 2011 ,and I think I will never buy any upgrade from mm again (until my machine can work)

You might be cutting off your nose to spite your face there. Compared to 2012, I can't see what was so special about 2011. (And indeed, if you search this forum, you'll find posts saying that 2011 wasn't half the version that 2010 was. :p )


"This is me helping."

Finale 2014, 2.6Ghz 2012 MacMini 16Gb RAM (10.9); 2009 MacBook
Edirol FA-66; M-Audio Oxygen 61; Yamaha PSR-410, HP Laserjet 5200 DTN
Ancient Groove Music www.ancientgroove.co.uk

Back to Top

Writer of Music
Registered Member



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Writer of MusicAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Aug 2011
Total Posts : 848
 
   Posted 11/28/2013 8:29 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
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

Jari Williamsson
Registered Member

Click to send Jari Williamsson email.Click to visit Jari Williamsson's website.Send a Private Message to Jari WilliamssonAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 1998
Total Posts : 3246
 
   Posted 11/29/2013 4:17 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
I said...
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.


Here's the video (which also celebrates that it's exactly 3 years since I was finished with the first plug-in using my then-new PDK Framework):
http://www.youtube.com/watch?v=6fePNFYsPtE&hd=1

Unfortunately, there's a technical issue on the finaletips.nu site right now - I'll post the JW Lua beta 0.12 and the scripts that were used for this demo once that has been resolved!


Jari Williamsson

Windows XP, Pentium 4
2.40 GHz, 4 GB RAM

www.finaletips.nu - The Finale Productivity Tips site

Back to Top

BvdPress
Registered Member

Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to BvdPressAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Nov 2001
Total Posts : 1006
 
   Posted 11/30/2013 10:28 AM (GMT -6)    Quote This PostAlert An Admin About This Post.
Wiggy said...
Bret Boulon said...
Hate 2014 so far; buggy and slow beyond hope.

Most impressions of it are that it is significantly faster and more responsive than previous versions. That's certainly been my experience. Perhaps this slowness on your computer can be sorted out?

Bret Boulon said...
Hated 2012.



For what it is worth, I bought a new Retina MacBook Pro a month before Finale 2014. I did two very small vocal charts and gave up on Finale 2014. It was slow, SUPER buggy and just not worth it to deal with the many problems.

Back to 2012 for me with lots of bitterness towards MakeMusic for the 2014 release.

As Writer of Music states, "Other's mileage varying, of course."


Bryan Doughty
BVD Press, Music Express and Cimarron Music
Oystein Baadsvik US tour coordinator - http://www.baadsvik.com/
[email protected] or [email protected]
http://www.bvdpress.com
http://www.cimarronmusic.com/

Back to Top

Jari Williamsson
Registered Member

Click to send Jari Williamsson email.Click to visit Jari Williamsson's website.Send a Private Message to Jari WilliamssonAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Dec 1998
Total Posts : 3246
 
   Posted 11/30/2013 3:54 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
Writer of Music said...
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.


If you mean the behaviour where the sound setup changes automatically (based on the Sound Map Priority) when you change the instrument in ScoreManager, that's by design.


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



Email Address Not AvailablePersonal Homepage Not AvailableSend a Private Message to Writer of MusicAIM Not AvailableICQ Not AvailableY! Not AvailableMSN Not Available
Date Joined Aug 2011
Total Posts : 848
 
   Posted 11/30/2013 4:17 PM (GMT -6)    Quote This PostAlert An Admin About This Post.
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
You cannot post new topics in this forum. You cannot reply to topics in this forum. Printable Version
165 posts in this thread.
Viewing Page :
 1  2  3  4  5  6  7 
   
Forum Information
Currently it is Saturday, December 5, 2020 3:18 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