Re: [Finale] Some comments re Fin09
[EMAIL PROTECTED] wrote: Seems to me that if they wanted to put in limitations for some publishing house, it would not be unreasonable to put in a policies configuration where you can select, say, the WB or BH guidelines and styles so the various houses get what they want. For the rest of us peons who have different guidelines, we can select the same old personal style we've been using since, well, forever. Bruce Exactly -- impairing potential in the program because publishers can't seem to be able to enforce submission guidelines strikes me as silly. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Craig Parmerlee wrote: I wonder if we should be giving them some benefit of the doubt on this subject. As a professional software designer for 35 years, it seems entirely plausible to me that they may have faced a point where preserving unlimited staff names, in combination with other new features. would have taken significant extra programming and testing effort. In cases like that, I believe it is appropriate for the system architects / business planners to make some judgments about their overall vision for the product. That seems to be the case in this instance. Their vision is, evidently, that they want to put their effort into the more elegant organization of expressions. If there were absolutely no trade-off involved and they made this change just to be hard-headed, that would be a bad deal. I really doubt that was the scenario though. That is my thinking on the subject as well, but the only justification brought out by the people at MakeMusic seems to be that publishers have asked for Finale to be more like Sibelius. Hard-headedness seems to be the only public justification given. I wonder what other Sibelius-like changes will be coming in the future versions, since Publishers seem to be able to get MakeMusic to jump when they want. Will they eliminate the pitch-first-then-rhythm data entry since Sibelius doesn't allow that? Will they muck up playback of some D.S. / D.C. forms since Sibelius doesn't play them back properly yet? How about data file format? Why don't the publishers demand that Finale provide Sibelius-format files so that submissions can come from either program but can be worked on in-house with only one program? I would love to know what sort of pressure to do things in a specific way that publishers are bringing to bear on Sibelius to try to get it to work more like Finale, if any? Is it only a one-way street? If so, where did Finale drop the ball and allow Sibelius to gain such a strong foothold that people can demand that Finale be more like Sibelius and actually get their way? -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Craig Parmerlee wrote: I wonder if we should be giving them some benefit of the doubt on this subject. As a professional software designer for 35 years, it seems entirely plausible to me that they may have faced a point where preserving unlimited staff names, in combination with other new features. would have taken significant extra programming and testing effort. At no point has anyone from MM ever claimed that the artificial limit was imposed by a technical constraint. Furthermore, speaking as one who knows something of Finale internals, including in particular Fin09 internals, I see no technical constraint. If you have 35 years of experience in IT, you'll understand this analogy. It's as if they have a relational table for staff lists which they are programatically (through the UI) forcing to have exactly 4 rows. At the data level, though, everything appears to be designed so that it could have any number of rows. Some of the other artificial limits in Finale (4 layers, 12 notes, etc.) are imposed by severe technical constraints. I do not believe that any such constraint currently exists for staff lists. The problem is, the longer we have the limit the more severe the technical constraint becomes, because as new code gets added that limit becomes an assumption that permeates all future development. (Which is why, for example, it is so hard to contemplate changing the number of layers now.) This is one of my biggest reasons for having pushed so hard on the staff list issue now. It is still fresh. I hasten to add that I am gleaning my impressions from having worked with the PDK, which since Fin06 has become progressively more wrapped and isolated from the true internals. But MM could easily shut this noise up by claiming there was a technical constraint, yet they have not. I basically trust them to be truthful, and a lot of my noise both here and on the forums is tough love. -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I didn't say it would be impossible to program F2009 to preserve unlimited staff lists. Clearly anything like this is possible. The point is that they very well could have faced a decision where simplifying the staff lists made their lives considerably easier. This might be a sensible business decision, considering the direction they are heading with the expressions. I agree with your points about springing it on the community without warning. I have never used more than 2 staff lists, so I'm sure I am not as sympathetic to the problem as I might be. [EMAIL PROTECTED] wrote: I am a programmer, too, and for about as long. I have encountered situations similar to what you've described below. There may be issues with having large staff lists (performance, field count bit size, whatever), but I can't see the reason for 4, as opposed to say, 8 or 16. I am not in their shoes, and maybe they've encountered a limit beyond my experience, but I find that hard to believe. They've removed features - they did not warn the user base, they did not deprecate old features, and I think that is what most find offensive. We have had no time to prepare, and have forced some of us to consider not upgrading (I did upgrade, by the way, and I like WinFin2k9). This is simply bad business. And, in the battle between business needs and programming, I have found that programming usually loses. Seeing as they have not cited any programming benefit, I can only conclude otherwise. Of course, if any of the MM lurkers wish to correct me, I will stand corrected on that point. Nevertheless: removal of a capability, no user base preparation (I mean all of us), and, in my mind, several workable alternatives to what they could have done, instead. Goodness - they could have written a plug-in that would scan the document and say hey, too many staff lists - WB will be upset! if it were just the publ houses. Sorry. As a long-time program project manager, this is a hot button for me. Craig Parmerlee [EMAIL PROTECTED] wrote: I wonder if we should be giving them some benefit of the doubt on this subject. As a professional software designer for 35 years, it seems entirely plausible to me that they may have faced a point where preserving unlimited staff names, in combination with other new features. would have taken significant extra programming and testing effort. In cases like that, I believe it is appropriate for the system architects / business planners to make some judgments about their overall vision for the product. That seems to be the case in this instance. Their vision is, evidently, that they want to put their effort into the more elegant organization of expressions. If there were absolutely no trade-off involved and they made this change just to be hard-headed, that would be a bad deal. I really doubt that was the scenario though. [EMAIL PROTECTED] wrote: Seems to me that if they wanted to put in limitations for some publishing house, it would not be unreasonable to put in a policies configuration where you can select, say, the WB or BH guidelines and styles so the various houses get what they want. For the rest of us peons who have different guidelines, we can select the same old personal style we've been using since, well, forever. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
John Howell wrote: At 8:54 AM -0400 8/2/08, dhbailey wrote: But why is this issue being raised now, when these same major publishers have been using Finale for many years? Why wasn't the staff-list limit lowered to 4 many years ago? That's the part that baffles me -- did these publishers simply wake up and say Oh, my goodness, you know we've been crippled by all these staff lists for all these years and didn't even know it? Ummm, did I miss something in all these identically-named posts, or am I correct in saying that NO PUBLISHER HAS ACTUALLY SAID THAT THIS IS A PROBLEM FOR THEM?!!! I thought someone just brought the possibility up out of thin air as an apologia for MakeMusic's unannounced, unexplained, and obviously unwanted arbitrary change. If I missed it, which publisher is it that made that statement? John No, way back in this thread, this was put forth as a reason specifically stated by MakeMusic as a reason. They supposedly sampled a large number of users, which included major publishers, and found that four was the ideal number somehow. The names of specific publishers was never mentioned, as I would expect and hope, simply because any complaint or suggestion should remain anonymous to the public at large. What hasn't been mentioned to my satisfaction is exactly what problems publishers would have due to large numbers of staff lists, nor why this problem has only now come forth when the program has not had such a restrictive limit on staff lists before. The solution was elegantly stated within the past few days, to the effect that publishers who don't want more than four staff lists, or who want the staff lists which get used to be defined or labeled in any specific manner can simply release Submission Guidelines which if not followed will result in immediate return of submitted materials (provided return postage is included). How difficult is it for Alfred (was Warner Brothers) or Hal Leonard (the two biggest publishers of music in the U.S. these days) to add the following items to any list of submission guidelines: 1) all works submitted must be created using Finale 2) all works shall have only four staff lists as the maximum, labeled as follows: 1; 2; 3; 4 2a) any works submitted with more than 4 staff lists shall be immediately returned for revision Why should all Finale users have to change their work-flow because some publishers felt it was easier to get Finale changed than to add a couple of conditions to their submission guidelines? That makes no sense whatsoever, so I think that MM may simply be using that as a smokescreen to hide the true reason for the limitation, one that they don't want to admit to. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
dhbailey wrote: I think that MM may simply be using that as a smokescreen to hide the true reason for the limitation, one that they don't want to admit to. What would that reason be, then? I can't think of one. Curious! ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 12:00 -0500 3/8/08, [EMAIL PROTECTED] wrote: Date: Sun, 03 Aug 2008 13:11:38 +0200 From: Barbara Touburg [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 To: finale@shsu.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed dhbailey wrote: I think that MM may simply be using that as a smokescreen to hide the true reason for the limitation, one that they don't want to admit to. What would that reason be, then? I can't think of one. Curious! as many of you are aware, a parallel discussion on SLs has been going on at http://forum.makemusic.com/default.aspx?f=6m=230216 (there are currently 58 posts over 3 pages. You can see all posts in one continuous html page if you choose Printable) re MM and publishers lobbying MM for 4 SLs a quick summary of the MM perspective is below Posted By : Tyler - Yesterday 4:32 AM Publishers have told MakeMusic that the fact Sibelius guides users into specific workflows has become a reason that they prefer to receive files in Sibelius format and prepare files in Sibelius. The most extensive rationale from Scott at MakeMusic (too long to include here) has come from (see his post at http://forum.makemusic.com/default.aspx?f=6m=230216 ): Posted By : Forum Admin - 8/1/2008 3:12 AM who subsequently posted this caveat: Posted By : Forum Admin - 8/2/2008 7:24 AM Perhaps I should reiterate that I am not personally an expert on subject of expressions, and that I did copy and paste much of the text of my mondo post from the work of others. That said, here's my two cents: I think that among the benefits of imposing an artifical limit on staff lists includes insuring that those who edit Finale files for a living, and receive submitted files from a variety of sources, don't have to work with files that have dozens of staff lists that were created by accident or because the user (like me) could never be bothered to remember which existing staff list did what and just made another and another... If you object to the staff list limitation on a philosophical basis, then posting your feelings in this forum is an excellent idea. If you object to this limitation because you've actually used the software, have fully explored the possibilities this new paradigm offers, and know that this limitation will actually make you less productive, then I'd ask that you share this information with our support staff so it can be properly logged and considered during future development. Scott at MakeMusic Forum Administrator MakeMusic, Inc. And then there was this post: Posted By : Tyler - Yesterday 4:32 AM Michael Mortilla said... Are you trying to protect us from ourselves? The goal is to make the program more efficient and easier to learn for more people than it has been in the past. That's the single largest problem facing Finale's future. Publishers have told MakeMusic that the fact Sibelius guides users into specific workflows has become a reason that they prefer to receive files in Sibelius format and prepare files in Sibelius. But even more importantly, new users have opted for Sibelius many times precisely because it is simpler, with fewer options that guide them into inefficient and frustratingly slow program usage. If your audience is solely made up of people who prepare music notation for a living, then including an option simply because somebody might have a use for it is a good enough reason. But when the vast majority of your audience includes people who can be negatively affected by that philosophy, you have to be a lot more careful in when and how you make those options available. Michael Mortilla said... Are you trying to keep our music more manageable; more conservative? There is absolutely nothing from a notation perspective that this staff list limitation makes impossible that was formerly possible. It only affects the method of accomplishing various tasks, not whether or not it can be done. So no, this doesn't keep music more conservative in the least. Robert P and many others have expressed support for the new Expressions paradigm but articulated well-reasoned scenarios and arguments for the retention of full SL capability, summed up by Robert as group-level SLs: Posted By : Robert Patterson - 8/2/2008 9:33 AM Meanwhile, the new paradigm makes staff lists more inviting than ever. Group-level staff lists is what this discussion is really about. The ability to define a staff list that displays on, e.g., one staff within a group in the score but all (or selected) staves within the part, for as many groups as I care to define. Drag-apply is utterly not the tool for it. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au
Re: [Finale] Some comments re Fin09
Seems to me that if they wanted to put in limitations for some publishing house, it would not be unreasonable to put in a policies configuration where you can select, say, the WB or BH guidelines and styles so the various houses get what they want. For the rest of us peons who have different guidelines, we can select the same old personal style we've been using since, well, forever. Bruce Claudio Pompili [EMAIL PROTECTED] wrote: snip MM perspective is below Posted By : Tyler - Yesterday 4:32 AM Publishers have told MakeMusic that the fact Sibelius guides users into specific workflows has become a reason that they prefer to receive files in Sibelius format and prepare files in Sibelius. The most extensive rationale from Scott at MakeMusic (too long to include here) has come from (see his post at http://forum.makemusic.com/default.aspx?f=6m=230216 ): Posted By : Forum Admin - 8/1/2008 3:12 AM snip ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I wonder if we should be giving them some benefit of the doubt on this subject. As a professional software designer for 35 years, it seems entirely plausible to me that they may have faced a point where preserving unlimited staff names, in combination with other new features. would have taken significant extra programming and testing effort. In cases like that, I believe it is appropriate for the system architects / business planners to make some judgments about their overall vision for the product. That seems to be the case in this instance. Their vision is, evidently, that they want to put their effort into the more elegant organization of expressions. If there were absolutely no trade-off involved and they made this change just to be hard-headed, that would be a bad deal. I really doubt that was the scenario though. [EMAIL PROTECTED] wrote: Seems to me that if they wanted to put in limitations for some publishing house, it would not be unreasonable to put in a policies configuration where you can select, say, the WB or BH guidelines and styles so the various houses get what they want. For the rest of us peons who have different guidelines, we can select the same old personal style we've been using since, well, forever. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I am a programmer, too, and for about as long. I have encountered situations similar to what you've described below. There may be issues with having large staff lists (performance, field count bit size, whatever), but I can't see the reason for 4, as opposed to say, 8 or 16. I am not in their shoes, and maybe they've encountered a limit beyond my experience, but I find that hard to believe. They've removed features - they did not warn the user base, they did not deprecate old features, and I think that is what most find offensive. We have had no time to prepare, and have forced some of us to consider not upgrading (I did upgrade, by the way, and I like WinFin2k9). This is simply bad business. And, in the battle between business needs and programming, I have found that programming usually loses. Seeing as they have not cited any programming benefit, I can only conclude otherwise. Of course, if any of the MM lurkers wish to correct me, I will stand corrected on that point. Nevertheless: removal of a capability, no user base preparation (I mean all of us), and, in my mind, several workable alternatives to what they could have done, instead. Goodness - they could have written a plug-in that would scan the document and say hey, too many staff lists - WB will be upset! if it were just the publ houses. Sorry. As a long-time program project manager, this is a hot button for me. Craig Parmerlee [EMAIL PROTECTED] wrote: I wonder if we should be giving them some benefit of the doubt on this subject. As a professional software designer for 35 years, it seems entirely plausible to me that they may have faced a point where preserving unlimited staff names, in combination with other new features. would have taken significant extra programming and testing effort. In cases like that, I believe it is appropriate for the system architects / business planners to make some judgments about their overall vision for the product. That seems to be the case in this instance. Their vision is, evidently, that they want to put their effort into the more elegant organization of expressions. If there were absolutely no trade-off involved and they made this change just to be hard-headed, that would be a bad deal. I really doubt that was the scenario though. [EMAIL PROTECTED] wrote: Seems to me that if they wanted to put in limitations for some publishing house, it would not be unreasonable to put in a policies configuration where you can select, say, the WB or BH guidelines and styles so the various houses get what they want. For the rest of us peons who have different guidelines, we can select the same old personal style we've been using since, well, forever. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
David, Spot on. This would preserve backward compatibility and meet the objection of it being too wild for the publishers. FWIW, I do not write for a publisher. I write for a private group of people. I haven't taken a survey, but I would venture a guess that many others do not either. I really don't care what publishers think about my manuscripts. My 2c. David W. Fenton [EMAIL PROTECTED] wrote: On 1 Aug 2008 at 8:22, Tyler Turner wrote: Having 50 different expression categories for dynamics so that they could each have a different staff list would slow those publishers down. Having any staff list at all for dynamics would make them unpredictable when positioning or deleting, and would thus also slow them down. The problem is a real one for these publishers, no doubt, but the solution that MM has provided for it seems to me to make no sense. Why not make the number of staff lists a template-based item? That is, when you create a template, you set the number of staff lists permanently for that file. Then the publishers could control this (I assume they are already using predefined template files, of course), while it leaves the rest of us the alternative to use as many staff lists as we choose. In short, it seems to me that a problem the publishers have in managing their engravers (a people problem) has become a problem for *all* Finale users. While it's important that publishers use Finale (it's one of the main things keeping it afloat), I don't see why such a Draconian solution to their very real engraver management problem should have been chosen. It really doesn't make any sense to me as either a Finale user or as a programmer. Of course, given that it is introduced at the same time as expression grouping and seems to have some kind of interaction with that feature, I fear that the restriction can't be removed or simply extended. *sigh* -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Tyler Turner wrote: --- On Fri, 8/1/08, dhbailey [EMAIL PROTECTED] wrote: I appreciate that link -- however I still see no reason that a publisher has been crippled by the different numbers of staff lists submission may have. Scott addressed this. In essence, having the more solid convention for when and where staff lists are used makes it more likely that publishers will be able to predict where staff lists are in place and makes it more likely they will be able to apply global or individual changes that do what they want without subtle gotchas. Having 50 different expression categories for dynamics so that they could each have a different staff list would slow those publishers down. Having any staff list at all for dynamics would make them unpredictable when positioning or deleting, and would thus also slow them down. But why is this issue being raised now, when these same major publishers have been using Finale for many years? Why wasn't the staff-list limit lowered to 4 many years ago? That's the part that baffles me -- did these publishers simply wake up and say Oh, my goodness, you know we've been crippled by all these staff lists for all these years and didn't even know it? And 50 different expression categories may slow the publishers down -- how about 75? Won't those do just what the former number of staff lists have done? It just seems like an issue which has suddenly exploded with no prior warning so that anybody could do anything about it or rethink their workflow, knowing in advance that a limit was going to come. Just another we don't have to tell you what we're doing until we've done it and you just have to live with it arrogance from another software company. How hard would it have been for MM to have indicated a year ago (or 2 or 10 or whenever the complaints about numerous staff lists started pouring in from publishers) that there would be a severe restriction on the number of staff lists, and actually tell us why (I still have seen no compelling reason why suddenly publishers are crippled by more than 4 staff lists, when they've lived with them for all these years) and when the limit would be imposed so that people could have been altering their workflow at their own pace, rather than being hit over the head with it when the annual we need the money upgrade was announced? For people working independently, it's a non-issue because they can just keep using an earlier version, but for people who are forced onto Fin2009, it'll cripple the users instead of the publishers. Who benefits? -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Allen Fisher wrote: So I guess these guys don't count: http://forum.makemusic.com/default.aspx?f=6m=230216 First couple of guys seem to like it just fine. Actually, only Wiggy seems happy with it, the others seem more like they're okay with it but haven't really gotten into it. The procedure he outlines as a workaround for not being about to use staff lists on some of the expression categories is a lot more work -- Drag vertically down a load of staves and the expression will appear on each stave [sic]. You can then delete each individually, if some of those staves don't need it. Doesn't sound like a less-effort replacement for a staff list which would define which of those staves which actually needed that expression? Sounds like a person would be better off simply using metatools to assign expressions. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 8:54 AM -0400 8/2/08, dhbailey wrote: But why is this issue being raised now, when these same major publishers have been using Finale for many years? Why wasn't the staff-list limit lowered to 4 many years ago? That's the part that baffles me -- did these publishers simply wake up and say Oh, my goodness, you know we've been crippled by all these staff lists for all these years and didn't even know it? Ummm, did I miss something in all these identically-named posts, or am I correct in saying that NO PUBLISHER HAS ACTUALLY SAID THAT THIS IS A PROBLEM FOR THEM?!!! I thought someone just brought the possibility up out of thin air as an apologia for MakeMusic's unannounced, unexplained, and obviously unwanted arbitrary change. If I missed it, which publisher is it that made that statement? John -- John R. Howell, Assoc. Prof. of Music Virginia Tech Department of Music College of Liberal Arts Human Sciences Blacksburg, Virginia, U.S.A. 24061-0240 Vox (540) 231-8411 Fax (540) 231-5034 (mailto:[EMAIL PROTECTED]) http://www.music.vt.edu/faculty/howell/howell.html We never play anything the same way once. Shelly Manne's definition of jazz musicians. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
But does it really matter? Why force the program to just have 4 because a publisher says so? Is make music going to start enforcing fonts as well? Are we all going to be stuck using Jazz font or something next? John Howell wrote: Ummm, did I miss something in all these identically-named posts, or am I correct in saying that NO PUBLISHER HAS ACTUALLY SAID THAT THIS IS A PROBLEM FOR THEM?!!! I thought someone just brought the possibility up out of thin air as an apologia for MakeMusic's unannounced, unexplained, and obviously unwanted arbitrary change. If I missed it, which publisher is it that made that statement? John ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Sat, Aug 2, 2008 at 1:32 PM, John Howell [EMAIL PROTECTED] wrote: NO PUBLISHER HAS ACTUALLY SAID THAT THIS IS A PROBLEM FOR THEM?!!! I thought someone just brought the possibility up out of thin air as an apologia for MakeMusic's ...snip... I've yet to heard any publishers say this for themselve, but it is reps of MM who claim they did. It's not just speculation by users. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I received FinMac2k9 a few hours ago and have had a quick look to ascertain the damage of the crippled Staff Lists. I've got that ole sinking feeling... I can see that being able to duplicate Categories could have opened up some exciting new possibilities if it had been coupled with unlimited Staff Lists. As it is, there might be some minor benefits to duplicating some of the Categories that have the 4 SLSs, from the point of view of housekeeping expressions into tidy groups, but that's about it. Compelling users to think in terms of tempo, expressive marks, dynamics categories is not necessarily a bad thing, if only they hadn't neutered the SLs. The new Expressions UI is OK but it quickly became a drag with lots of mouse movement/scrolling to navigate around. I don't know about others, in most dialog/selection boxes (eg the OSX Finder dialogs) I expect to be able to type in the beginning letter or letters of a text string and expect the dialog box to automatically scroll to the entry and highlight/select it. I've been waiting for this for years in the Measure Expressions dialogs and the saving grace was TGTools' Staff Expression sorter. But instead MM have opted to give us another 'one size fits all' solution and take us back to the stone age with the Note Expressions UI, ie a whole bunch of glyphs in a grid (OK the resize is a nice addition if it were properly implemented). In order to get the new Expression UI to look like a list I had to zoom out to max (more mouse clicks!). And still no auto scroll with quick access via keyboard entry. Sheee. If only MM had opted for something like the OSX Finder windows which all have three standard views (icons, list and columns) with keystrokes or radio buttons AND auto scroll on keyboard entry. Like DUH... I also checked the old Bookmarks function which went flaky I think couple of versions back (it doesn't sort alphabetically but something like reverse chronological but not quite!). I use Bookmarks often as a quick way to get around a score that often has measured, unmeasured sections and combos often user-defined measure numbers. I find it a drag to have to constantly think in either measure or page numbers. When they sorted alphabetically it was easy to set up a systematic sequence and zip around the score quickly. I did some quick tests on other files where I've used extensive bookmarks and it appears that having the default text Bookmark as the initial string seems to help in making it sort alphabetically most of the time. I opened a brand new 2k9 file from a template and added the following entries in chronological order at a distance of 2 measures apart (except for the Scene2b which is allocated to the measure immediately following Scene2): Act1Scene1, Act1Scene2, Act1Scene3, Bookmark Act1Scene1, Bookmark Act1Scene2, Bookmark Act1Scene3, Bookmark Act1Scene2b and Way To Go 'Diva' Aria. And after I closed the dialog and opened it again they appeared as follows: Way To Go 'Diva' Aria Act1Scene3 Act1Scene2 Act1Scene1 Bookmark Act1Scene1 Bookmark Act1Scene2 Bookmark Act1Scene2b Bookmark Act1Scene3 This is a fairly elementary and necessary navigation tool (I'm thinking along similar lines of the Memory tools in Pro Tools or Logic Pro which can be allocated to beats or time code along the usual other assignments such as views, zoom functions etc). The Bookmarks list in Finale should be able to be sorted (all modes should have ascending or descending or forward/backward numberings) according to different criteria such as alphabetically, by measure numbers (actual or user defined), chronologically in order of entry or chronologically according to time code (since Finale is moving ever closer to being something like a DAW with the addition of imported video playback). -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Tyler Turner wrote: --- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: I don't understand how the number of staff lists a person uses would in any way be an inconvenience to a publisher. How would it create more work for a publisher? Scott summarized the issues here: http://forum.makemusic.com/default.aspx?f=6m=230216p=2 I appreciate that link -- however I still see no reason that a publisher has been crippled by the different numbers of staff lists submission may have. If that's the case, why wasn't there a demand to restrict staff lists to 4 years and years ago? Why now? Why has the number of staff lists suddenly become a problem for publishers that they have asked for a limit with Finale2009 and they didn't ask for that limit with Finale97? Or version 2? (I wasn't using Finale then -- were there staff lists then?) -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
in answer to my previous post re dodgy Bookmarks sorting. I tried some alternatives in FinMac2k6d and added about 20 numbers to a new default file. It appears that by commencing the Bookmark name with the string '01_', '02_', '03_' etc it sorts correctly from top to bottom in the list. Insertions such as '011_', '012_' position themselves correctly in the top/down list also. So far so good in Fin2k6d. I opened this same file in FinMac2k9 and the Bookmark list looked OK in proper top/down order. I then added some more insertions with the preceding digits strings. Bummer. They went to the top of the list. However, after some time I quit and relaunched the app and the Bookmarks list sorted correctly. Returned to the Fin2k6d file and added extra insertions as per the Fin2k9 file and they sorted themselves immediately. pretty erratic behaviour from a basic navigation tool from version to version and neither of them handle alphabetical sorting predictably. (BTW I'm on Mac PPCG4 1.25GHz DP, 2GB RAM, OSX 10.4.11) -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
--- On Fri, 8/1/08, dhbailey [EMAIL PROTECTED] wrote: I appreciate that link -- however I still see no reason that a publisher has been crippled by the different numbers of staff lists submission may have. Scott addressed this. In essence, having the more solid convention for when and where staff lists are used makes it more likely that publishers will be able to predict where staff lists are in place and makes it more likely they will be able to apply global or individual changes that do what they want without subtle gotchas. Having 50 different expression categories for dynamics so that they could each have a different staff list would slow those publishers down. Having any staff list at all for dynamics would make them unpredictable when positioning or deleting, and would thus also slow them down. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Fri, Aug 1, 2008 at 10:22 AM, Tyler Turner [EMAIL PROTECTED] wrote: Having 50 different expression categories for dynamics so that they could each have a different staff list would slow those publishers down. When, oh when will you stop waving this red flag in front of the bull? By what right does MM assume that its users are idiots or can't decide for themselves when to use a staff list? And let us be clear. My reaction is thus because the *only* justification for the 4-limit that I've heard from you or any other person connected with MM boils down to, We limited the number of SLs because users are too stupid to use more than that number appropriately. Paraphrasing from a post I saw on the Finale Forum, what's next? Will you limit the number of beams to 4 because more than that is deemed inappropriate? Or will you limit transpositions to only those which MM and its advisers understand? Or will you limit the number and positioning of staff lines to those you think are appropriate? Where does it end? BTW: It is to laugh, Tyler's claim that there are posters on the Finale Forums that argue the 4-limit is a good thing. There are a (seemingly very) few who are willing to live with the limit. Not a single user that I've seen views it as an improvement. (By contrast, many users including me champion the new Expression tool in general. I'm speaking specifically of the 4-SL limit/requirement.) ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
So I guess these guys don't count: http://forum.makemusic.com/default.aspx?f=6m=230216 First couple of guys seem to like it just fine. On Aug 1, 2008, at 10:53 AM, Robert Patterson wrote: On Fri, Aug 1, 2008 at 10:22 AM, Tyler Turner [EMAIL PROTECTED] wrote: Having 50 different expression categories for dynamics so that they could each have a different staff list would slow those publishers down. When, oh when will you stop waving this red flag in front of the bull? By what right does MM assume that its users are idiots or can't decide for themselves when to use a staff list? And let us be clear. My reaction is thus because the *only* justification for the 4-limit that I've heard from you or any other person connected with MM boils down to, We limited the number of SLs because users are too stupid to use more than that number appropriately. Paraphrasing from a post I saw on the Finale Forum, what's next? Will you limit the number of beams to 4 because more than that is deemed inappropriate? Or will you limit transpositions to only those which MM and its advisers understand? Or will you limit the number and positioning of staff lines to those you think are appropriate? Where does it end? BTW: It is to laugh, Tyler's claim that there are posters on the Finale Forums that argue the 4-limit is a good thing. There are a (seemingly very) few who are willing to live with the limit. Not a single user that I've seen views it as an improvement. (By contrast, many users including me champion the new Expression tool in general. I'm speaking specifically of the 4-SL limit/requirement.) ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Allen Fisher Founder and Principle Developer Fisher Art and Technology [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
And there are a ton of people who don't? Flag...waving.bull? Taking away features is generally a bad thing. People who have been using them don't like it. Plain and simple. A better solution would have been to say If you want to use the new Markings, you need to limit your staffs to 4, otherwise, the behavior of the markings will revert to pre-Finale 2009. That would have been a better way to handle it rather than just..bloop...you can only have 4. On Fri, Aug 1, 2008 at 9:16 AM, Allen Fisher [EMAIL PROTECTED]wrote: So I guess these guys don't count: http://forum.makemusic.com/default.aspx?f=6m=230216 First couple of guys seem to like it just fine. On Aug 1, 2008, at 10:53 AM, Robert Patterson wrote: On Fri, Aug 1, 2008 at 10:22 AM, Tyler Turner [EMAIL PROTECTED] wrote: Having 50 different expression categories for dynamics so that they could each have a different staff list would slow those publishers down. When, oh when will you stop waving this red flag in front of the bull? By what right does MM assume that its users are idiots or can't decide for themselves when to use a staff list? And let us be clear. My reaction is thus because the *only* justification for the 4-limit that I've heard from you or any other person connected with MM boils down to, We limited the number of SLs because users are too stupid to use more than that number appropriately. Paraphrasing from a post I saw on the Finale Forum, what's next? Will you limit the number of beams to 4 because more than that is deemed inappropriate? Or will you limit transpositions to only those which MM and its advisers understand? Or will you limit the number and positioning of staff lines to those you think are appropriate? Where does it end? BTW: It is to laugh, Tyler's claim that there are posters on the Finale Forums that argue the 4-limit is a good thing. There are a (seemingly very) few who are willing to live with the limit. Not a single user that I've seen views it as an improvement. (By contrast, many users including me champion the new Expression tool in general. I'm speaking specifically of the 4-SL limit/requirement.) ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Allen Fisher Founder and Principle Developer Fisher Art and Technology [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Fri, Aug 1, 2008 at 11:16 AM, Allen Fisher [EMAIL PROTECTED] wrote: First couple of guys seem to like it just fine. On the contrary. They don't object to it. That's hardly the same thing. Show me one user who prefers it. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Allen Fisher wrote: I concur, Wiggy. Thanks. You've pretty much convinced me that F2009 is worth moving to at this point. An endoresement of Fin09 is not an endorsement of the 4-SL limit. Heck, as vocal as I am about this issue, I endorse Fin09 in general. I think the new expression tool is overall a solid improvement, and I may even adopt Fin09 with the maintenance release. I do not believe the poster quoted above was saying he (she?) approved of the 4-SL limit. I read that post as, well on balance I guess I can live with the 4-SL limit to get the other Fin09 goodness. Maybe we each see what we wish to see. It was rather disingenuous to use that thread as an example, considering the vitriol that follows the first couple of posts (and not just my own vitriol). It seems the folks at MM willfully misterpret me, too. I have never said I want to go back to the old way of doing staff lists, or even to have them as a compatibility option. What I am saying is I want the ability to define the number of NEW staff lists in my file, from 0 to as high as I need to go. This does not appear to be, nor has MM claimed it is hard to do programmatically, so what is the BFD? -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
--- On Fri, 8/1/08, Robert Patterson [EMAIL PROTECTED] wrote: When, oh when will you stop waving this red flag in front of the bull? In case you didn't notice, Robert, I was asked the question specifically. So don't complain about me answering it or how I answer it. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 12:27 PM 8/1/2008, Robert Patterson wrote: On the contrary. They don't object to it. That's hardly the same thing. Show me one user who prefers it. I have to agree with Robert's distinction here. In addition, their lack of objection seems to be based on the fact that these are users who had been using staff lists as a substitute for the not-yet-available drag-apply for expressions. Now that they have drag-apply, they're happy. But as has been pointed out here, there are legitimate uses for staff lists for which drag-apply is *not* an acceptable substitute. Personally, I don't really have a dog in this race. I only ever used staff lists for things like tempo markings and rehearsal marks, and so the new paradigm works for me just fine. However, I agree very strongly with the sentiment expressed, that reducing functionality in a program like this is a bad thing, full stop. Seeing how this was done makes me worry about how Speedy Entry will ultimately be handled, which *is* something that concerns me greatly. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Aaron Sherber wrote: Personally, I don't really have a dog in this race. I only ever used staff lists for things like tempo markings and rehearsal marks, and so the new paradigm works for me just fine. You actually do have a (smallish) chihuahua in the race. I'm arguing for *no* limit. Right now you are forced to have 4 even if you only need 1. This may seem a small thing, but since you can change the names or even give them meaningful names, how are you gonna remember which one is which? -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Yes, seeing how they handled this, an for the people who used that feature, they have little recourse. I can see them doing something similar at some point with speedy entry, with similar rationalizations. On Aug 1, 2008, at 11:00 AM, Aaron Sherber [EMAIL PROTECTED] wrote: However, I agree very strongly with the sentiment expressed, that reducing functionality in a program like this is a bad thing, full stop. Seeing how this was done makes me worry about how Speedy Entry will ultimately be handled, which *is* something that concerns me greatly. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 02:56 PM 8/1/2008, Robert Patterson wrote: You actually do have a (smallish) chihuahua in the race. I'm arguing for *no* limit. Right now you are forced to have 4 even if you only need 1. This may seem a small thing, but since you can change the names or even give them meaningful names, how are you gonna remember which one is which? I agree that we should be able to rename the lists. I understand your point about often needing fewer than 4 lists -- in most of my work, I only use one -- but I don't think I feel any resentment or ill effects from being forced to have 4. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 1 Aug 2008 at 8:22, Tyler Turner wrote: Having 50 different expression categories for dynamics so that they could each have a different staff list would slow those publishers down. Having any staff list at all for dynamics would make them unpredictable when positioning or deleting, and would thus also slow them down. The problem is a real one for these publishers, no doubt, but the solution that MM has provided for it seems to me to make no sense. Why not make the number of staff lists a template-based item? That is, when you create a template, you set the number of staff lists permanently for that file. Then the publishers could control this (I assume they are already using predefined template files, of course), while it leaves the rest of us the alternative to use as many staff lists as we choose. In short, it seems to me that a problem the publishers have in managing their engravers (a people problem) has become a problem for *all* Finale users. While it's important that publishers use Finale (it's one of the main things keeping it afloat), I don't see why such a Draconian solution to their very real engraver management problem should have been chosen. It really doesn't make any sense to me as either a Finale user or as a programmer. Of course, given that it is introduced at the same time as expression grouping and seems to have some kind of interaction with that feature, I fear that the restriction can't be removed or simply extended. *sigh* -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
--- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: I don't understand how the number of staff lists a person uses would in any way be an inconvenience to a publisher. How would it create more work for a publisher? Scott summarized the issues here: http://forum.makemusic.com/default.aspx?f=6m=230216p=2 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
From there we enlisted input from a broad spectrum of Finale professionals Oh, you mean like people on the Finale list.or.on the forums orexactly from where where these broad spectrum of people found again? Tyler Turner wrote: --- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: I don't understand how the number of staff lists a person uses would in any way be an inconvenience to a publisher. How would it create more work for a publisher? Scott summarized the issues here: http://forum.makemusic.com/default.aspx?f=6m=230216p=2 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Some comments re Fin09
There are several forum users who were contacted and interviewed. We also went to engravers who worked for some of the larger houses in the country. Not sure if I'm allowed to reveal names. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Thursday, July 31, 2008 12:15 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 From there we enlisted input from a broad spectrum of Finale professionals Oh, you mean like people on the Finale list.or.on the forums orexactly from where where these broad spectrum of people found again? Tyler Turner wrote: --- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: I don't understand how the number of staff lists a person uses would in any way be an inconvenience to a publisher. How would it create more work for a publisher? Scott summarized the issues here: http://forum.makemusic.com/default.aspx?f=6m=230216p=2 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Scott explains well how the new staff lists give us advantages, but not how a piece with many staff lists would create more work for a publisher. I cannot see why this should be so. I am happy with the new behaviour for my own work, since I have always entered dynamics and the like as separate note-attached expressions. I have never needed more than 3 staff lists. I am particularly happy to be able to add items with staff lists using metatools: this wasn't possible before. Having said that for myself, I don't see why those of us who are used to working with many more staff lists should be penalised. And the staff lists are still all there in the document: you'll find them in the repeat tool, but you can no longer use them for expressions. We are allowed to create as many expression categories as we like (as a test, I created more than 40). Most users probably won't create any more than the ones that are already there, but the possibility is there for anybody who might need it. Why not keep the same possibility for staff lists? Michael On 31 juil. 08, at 18:39, Tyler Turner wrote: --- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: I don't understand how the number of staff lists a person uses would in any way be an inconvenience to a publisher. How would it create more work for a publisher? Scott summarized the issues here: http://forum.makemusic.com/ default.aspx?f=6m=230216p=2 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Name 3 that thought this (in its current form) was a good idea. On Jul 31, 2008, at 1:43 PM, Fisher, Allen wrote: There are several forum users who were contacted and interviewed. We also went to engravers who worked for some of the larger houses in the country. Not sure if I'm allowed to reveal names. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Thursday, July 31, 2008 12:15 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 From there we enlisted input from a broad spectrum of Finale professionals Oh, you mean like people on the Finale list.or.on the forums orexactly from where where these broad spectrum of people found again? Tyler Turner wrote: --- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: I don't understand how the number of staff lists a person uses would in any way be an inconvenience to a publisher. How would it create more work for a publisher? Scott summarized the issues here: http://forum.makemusic.com/ default.aspx?f=6m=230216p=2 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale John Blane Blane Music Preparation 1649 Huntington Ln. Highland Park, IL 60035 847 579-9900 847 579-9903 fax www.BlaneMusic.com [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: To Lurk or Not to Lurk... was: RE: [Finale] Some comments re Fin09
Allen, Thank you for offering to speak with someone at MakeMusic about getting an official presence here. I am sad that it probably won't be you, as you appear to have a terrific grasp of the program as well as a personality which appears to be able to explain things in a calm and clear manner. In any event, whether the people who would make such a decision agree with you or not about an official presence on this list, I just want you to know that your presence here has been much appreciated by me and I know also by many others on this list. Thank you, David H. Bailey Fisher, Allen wrote: That's not why I'm quieting down. I unintentionally hijacked the 2k9 thread. I got a bit snarky with Eric D, and I apologize for that. I'd rather have you discussing the merits of the product than arguing about my presence here, especially on the 2k9 thread. That said, I will talk to someone about getting an official presence here (probably won't be me, as much as I enjoy chatting with most people here...). I can't make any promises though, just like I can't comment on on-going development. [snip] -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
David W. Fenton wrote: [snip] If they are right, why wouldn't the problem take care of itself? Why cripple the old way in order to force people to use the new way? That's a very good question, and one which I think the answer to involves more complexity than simple arbitrary restriction to 4 staff lists. I think there may be a programming issue where underlying changes in the way the program works might have made internal tracking or control of more than 4 staff lists difficult. Absent a true programming need, there is no logical reason for such a limitation because any such change in the number of staff lists would have involved programming time which would better have been spent elsewhere. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Wed, Jul 30, 2008 at 8:42 AM, dhbailey [EMAIL PROTECTED] wrote: I think there may be a programming issue where underlying changes in the way the program works might have made internal tracking or control of more than 4 staff lists difficult. I do not know any more about how this function evolved than anyone else on this list. I could speculate that they may have originally planned to have only hard-wired staff lists (i.e., completely uneditable), then thought better of it. What makes me say this is that you can find 4 names that look like they may be staff list names in the datafile that are currently not used. They are generic names that match up with the category names fairly closely. Furthermore, nothing about the data structures that I can see as a plugin developer precludes the possibility of lifting the artificial limit. If they lifted the limit, there is definitely more programming work they would have to do, mainly to do with libraries. I do not believe the staff lists get copied with an expression library: only the 1, 2, 3, 4 assignments are copied. If they opened up staff lists, they would have to be included in expression libraries. That said, I have not heard one iota of a word from MM that the limit has anything to do with programming priorities or time constraints. I'd feel better about it if I had. On the contrary, MM so far has steadfastly justified it as a designed and planned enahancement to the program. That is why it is incumbent upon us users to disabuse them of their folly. You know, the limit of 4 is not the only problem. I would like to have the option of *fewer* staff lists than 4. Many of my pieces require only 1, and the rest are just clutter. Why force us to have any certain number of them? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
--- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: Absent a true programming need, there is no logical reason for such a limitation because any such change in the number of staff lists would have involved programming time which would better have been spent elsewhere. I don't think that would be the case. Given the new design, I think it's a good bet they had to redo a bunch of the staff list functionality anyway, and if anything, it would probably have been extra programming effort to allow for the ability to create staff lists in the new system. Regardless, I don't think that's the reason it's not in there. I think the reason it's not in there is related to publishers complaining about receiving user files that had terribly indiscriminate use of staff lists which translated into more work for them. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Wed, Jul 30, 2008 at 10:24 AM, Tyler Turner [EMAIL PROTECTED] wrote: I think the reason it's not in there is related to publishers complaining about receiving user files that had terribly indiscriminate use of staff lists which translated into more work for them. Given the new paradigm for staff lists (and, yes, the availability of drag-assign), do you honestly believe that users would still use them indiscriminately if the limit were lifted? Suppose they did? What of it? In order to use them they'd also have to indiscriminately create categories and then indiscriminately assign expressions to those categories. Where do you draw the line? Not to mention, as I said in my earlier post, 4 lists is already indiscriminate for 80% of my work. I'd like the option of only having one. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
So big business is now dictating feature reductions? Stupid. There should have been a compromise or something. If you have more than 4 staff lists only the first 4 can support the new measure expressions. After that, it would be like previous versions. Something like that would have been a better way to deal with it..at least for people who have been using the feature a lot. On Wed, Jul 30, 2008 at 8:24 AM, Tyler Turner [EMAIL PROTECTED] wrote: --- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: Absent a true programming need, there is no logical reason for such a limitation because any such change in the number of staff lists would have involved programming time which would better have been spent elsewhere. I don't think that would be the case. Given the new design, I think it's a good bet they had to redo a bunch of the staff list functionality anyway, and if anything, it would probably have been extra programming effort to allow for the ability to create staff lists in the new system. Regardless, I don't think that's the reason it's not in there. I think the reason it's not in there is related to publishers complaining about receiving user files that had terribly indiscriminate use of staff lists which translated into more work for them. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I believe it was mentioned here that the limit on staff lists is not present in the repeat tool. To this non-programmer, that seems to be the most curious thing in all of this. In 2006 (my current version), as far as I can tell, the repeat tool accesses the same group of staff lists that are available for use with expressions. Are there two *different* staff lists now, or do the four lists for expressions show up for use with repeats? And if the expression staff lists *are* available to use with repeats, what happens to repeat staff lists over and above the four on the expression side? Are they grayed out? I wonder if repeat staff lists, unlimited as they are, might be an adequate (and hopefully temporary) substitute for some of the usage described here by Claudio, Bernard and others. Don Hart On 7/30/08 10:02 AM, Robert Patterson [EMAIL PROTECTED] wrote: On Wed, Jul 30, 2008 at 8:42 AM, dhbailey [EMAIL PROTECTED] wrote: I think there may be a programming issue where underlying changes in the way the program works might have made internal tracking or control of more than 4 staff lists difficult. I do not know any more about how this function evolved than anyone else on this list. I could speculate that they may have originally planned to have only hard-wired staff lists (i.e., completely uneditable), then thought better of it. What makes me say this is that you can find 4 names that look like they may be staff list names in the datafile that are currently not used. They are generic names that match up with the category names fairly closely. Furthermore, nothing about the data structures that I can see as a plugin developer precludes the possibility of lifting the artificial limit. If they lifted the limit, there is definitely more programming work they would have to do, mainly to do with libraries. I do not believe the staff lists get copied with an expression library: only the 1, 2, 3, 4 assignments are copied. If they opened up staff lists, they would have to be included in expression libraries. That said, I have not heard one iota of a word from MM that the limit has anything to do with programming priorities or time constraints. I'd feel better about it if I had. On the contrary, MM so far has steadfastly justified it as a designed and planned enahancement to the program. That is why it is incumbent upon us users to disabuse them of their folly. You know, the limit of 4 is not the only problem. I would like to have the option of *fewer* staff lists than 4. Many of my pieces require only 1, and the rest are just clutter. Why force us to have any certain number of them? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Tyler Turner wrote: --- On Wed, 7/30/08, dhbailey [EMAIL PROTECTED] wrote: Absent a true programming need, there is no logical reason for such a limitation because any such change in the number of staff lists would have involved programming time which would better have been spent elsewhere. I don't think that would be the case. Given the new design, I think it's a good bet they had to redo a bunch of the staff list functionality anyway, and if anything, it would probably have been extra programming effort to allow for the ability to create staff lists in the new system. Regardless, I don't think that's the reason it's not in there. I think the reason it's not in there is related to publishers complaining about receiving user files that had terribly indiscriminate use of staff lists which translated into more work for them. I don't understand how the number of staff lists a person uses would in any way be an inconvenience to a publisher. How would it create more work for a publisher? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 30.07.2008 Tyler Turner wrote: I think the reason it's not in there is related to publishers complaining about receiving user files that had terribly indiscriminate use of staff lists which translated into more work for them. No, that surely is not the reason. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 28.07.2008 Fisher, Allen wrote: That said, since I've distracted everyone from discussing Finale by accidentally including my signature and taking a vacation day, I think it's best that I shut up for a while. Well, you see that is partly why people criticize you, I believe: as soon as it gets a little hot you can dive away. I am not criticising you for this as I realize that you are in a tricky seat, but I think MM should rethink this and send someone to officially be present here. It would avoid a lot of misunderstandings. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 28.07.2008 Eric Dannewitz wrote: Still think you should strongly suggest to your employer that you be allowed to answer questions on this list (and perhaps others) in an official manner. Why not spend 30 minutes or so fielding questions (or someone fielding questions) rather than this we are here, but unofficially thing. Sibelius does it. MakeMusic seems to be copying Sibelius in everything else.,.,, I agree, and I think people would understand much more easily if you then couldn't answer certain question, ie will the next version do this or that. But simply the fact that it then seems like MM is actually communicating directly will make a lot of us much happier. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Tyler Turner wrote: Flexibility only works in Finale's favor if the implementation always makes it clear what the BEST method is in a given situation. It just sickens me to see one MM employee or ex-employee after another try to justify what is plainly a bull-headed, arbitrary, and user-underestimating decision. I have yet to see a single actual, you know, *user* argue that we only need 4 staff lists. I've seen some say they can live with it, but that's hardly a ringing endorsement. (It will only last until the day they *can't* live with it.) Clarifying usage is a far cry from feature confiscation. Drag-apply is a very poor substitute for staff lists. Conversely, staff lists are a poor subtitute for drag-apply. They each have their different uses, and the Fin09 implementation has (successfully in my view) clarified the distinction. All the more reason the arbitrary limit of 4 staff lists is pure feature confiscation. Finally, I would remind Tyler that some of the worst abuses of staff lists were caused not by Finale's users, who may not collectively be so stupid as it seems MM gives them credit for. Rather, many of the worst abuses of staff lists were apparently caused by a bug in Fin08. -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Tyler Turner wrote: --- On Mon, 7/28/08, Robert Patterson [EMAIL PROTECTED] wrote: What augers worst for me in this attitude is the clear Sibeliusation trend. Sibelius always took knocks because it wasn't as flexible as Finale. When the Finn brothers were in charge Sib was willfully inflexible. Now MM seems to want to throw away their competitive edge with both hands and embrace the Finn brothers' ideas about flexibility. Sibelius' lack of flexibility is really the thing that allowed it to survive and make it in this market. Flexibility only works in Finale's favor if the implementation always makes it clear what the BEST method is in a given situation. And that is the single largest problem Finale has faced all along. Finale's flexibility is really only attractive to a fairly small (but important) percentage of its users - for the rest, it has served as a stumbling block that makes the program take longer to learn and slower to use. Inevitably, people end up using less than ideal tools for completing their work in Finale, and that goes for people of all experience levels. I've never seen anyone who truly uses the best tool for the job in Finale 100% of the time. Sibelius isn't perfect that way, but having fewer ways to accomplish most tasks has definitely helped them funnel people into techniques that are often more effective than the ones people stumble upon in Finale. Sibelius' lack of flexibility (especially early on) may have given it a slow start with engravers, but it was exactly the thing that brought it success with college students and other new users that join the market each year. Starting in an inflexible mindset has allowed Sibelius to gradually become more flexible, allowing more and more user control (they do still have a ways to go to match Finale's flexibility in every aspect) and thus looking more favorable as each new version has come out. This has given Sibelius users the impression (valid or not) that Sibelius is responsive to the concerns of the end-user, that the company listens and cares and does something about it. Being flexible as Finale has been means that when it makes what appear to be arbitrary decisions to limit that flexibility it only antagonizes current users who may have grown accustomed to depending on that very flexibility that Finale is removing. It appears as a product which is no longer concerned very much with its user base. Was there a huge outcry on the official Finale forum from users that having so many staff lists was a hindrance and should be restricted? I doubt it. So who exactly were they listening to? People they were already paying. Instead of listening to people who are paying them. I guess the folks in charge of running the business at MakeMusic were asleep during that class at business school where they should have learned that a company should ask its employees and contractors about improvements in running the company but they should ask their paying customers about changes in the products the customers are paying for. Finale is still more flexible than Sibelius in a lot of areas, yet the perception is that Finale is becoming inflexible, which is something that worries long-term users. What's next for Finale to remove from our toolboxes? And more importantly, what was the reasoning for the limiting of staff-styles? If it isn't a programming issue, then they could have kept the larger number it had. If it is a programming issue, then why are they continually forcing ever-more-rigid versions out the door too early in an effort to keep their annual-upgrade cash flow going? Isn't SmartMusic holding its end of the company up? If not, then why did they take developers away from Finale and why are they pushing SmartMusic so much more than Finale? If SmartMusic *is* holding its own, then why can't MakeMusic stop the annual shove it out the door, ready or not process and take a bit longer between the upgrades for Finale. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
--- On Tue, 7/29/08, Robert Patterson [EMAIL PROTECTED] wrote: It just sickens me to see one MM employee or ex-employee after another try to justify what is plainly a bull-headed, arbitrary, and user-underestimating decision. I have yet to see a single actual, you know, *user* argue that we only need 4 staff lists. Look on MakeMusic's forum. Drag-apply is a very poor substitute for staff lists. It depends on the use. The problem is that many people were using staff lists for situations where drag-apply really is much smarter. Finally, I would remind Tyler that some of the worst abuses of staff lists were caused not by Finale's users, who may not collectively be so stupid as it seems MM gives them credit for. Rather, many of the worst abuses of staff lists were apparently caused by a bug in Fin08. And I'm going to remind you that having worked with many thousands of Finale users has given me a pretty good perspective on Finale's weaknesses for the majority of its users. Believe me, the same flexibility that has worked in its favor for appealing to power users has very much worked against it in the battle for new users. If you're going to provide 20 ways to do something, you'd better be able to obscure 19 of them so that users always first pick the one that's usually most efficient. There's a huge tendency for people to stick with the first technique they learn for accomplishing something in Finale. When that technique makes them slow and inefficient, it makes it that much easier for Sibelius to appeal to them. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Tue, Jul 29, 2008 at 9:03 AM, Tyler Turner [EMAIL PROTECTED] wrote: The problem is that many people were using staff lists for situations where drag-apply really is much smarter. No argument with that here. What I'm saying is MM wants to force people to use drag-apply when staff lists are really much smarter. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Tue, Jul 29, 2008 at 9:03 AM, Tyler Turner [EMAIL PROTECTED] wrote: Look on MakeMusic's forum. I looked. What I saw is a lot of people learning to live with an arbitrary limitation. I also saw a lot of posters who apparently don't need section-level staff lists, which is what the outrage over the takeaway is really about. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Yes, yes, yes. This is absolutely true. Tyler, I'm glad you were able to articulate this fundamental issue so clearly. That summarizes 10 years of frustration for me. I have worked in the software business for 30+ years and pretty open to learning curve issues. I feel like I have been able to assimilate 70% +- of what Finale has to offer. But unless a person is a professional copyist working with the program at least 10-20 hours a week, I just don't believe one can really get really in touch with the program. To underscore the point, I attended a master class last evening with a local professor, and we rehearsed a new piece he had written. (A really nice composition, I might add.) This is a guy who obviously spends considerable time on Finale. His purpose is to commit his musical inspirations to paper, not to become a software junkie. I think you all know what the result was. It was a legible piece of music that worked. The extracted parts were out of sync with the score. He lamented that Finale should add cautionary accidentals. (Of course, it can, but you have to dig for that.) Lots of markings were misplaced or covered because of collisions. I'm not being critical. He is a composer -- and a really good one. He isn't a software specialist or professional copyist. Finale is the best software ever for the professional copyist. For the artist -- not so much. My knowledge base is 2007. It is possible that MM has closed that copyist/artist gap in 2008 and 2009. I hope so. Tyler Turner wrote: --- On Mon, 7/28/08, Robert Patterson [EMAIL PROTECTED] wrote: Flexibility only works in Finale's favor if the implementation always makes it clear what the BEST method is in a given situation. And that is the single largest problem Finale has faced all along. Finale's flexibility is really only attractive to a fairly small (but important) percentage of its users - for the rest, it has served as a stumbling block that makes the program take longer to learn and slower to use. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
To Lurk or Not to Lurk... was: RE: [Finale] Some comments re Fin09
That's not why I'm quieting down. I unintentionally hijacked the 2k9 thread. I got a bit snarky with Eric D, and I apologize for that. I'd rather have you discussing the merits of the product than arguing about my presence here, especially on the 2k9 thread. That said, I will talk to someone about getting an official presence here (probably won't be me, as much as I enjoy chatting with most people here...). I can't make any promises though, just like I can't comment on on-going development. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johannes Gebauer Sent: Tuesday, July 29, 2008 4:16 AM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 On 28.07.2008 Fisher, Allen wrote: That said, since I've distracted everyone from discussing Finale by accidentally including my signature and taking a vacation day, I think it's best that I shut up for a while. Well, you see that is partly why people criticize you, I believe: as soon as it gets a little hot you can dive away. I am not criticising you for this as I realize that you are in a tricky seat, but I think MM should rethink this and send someone to officially be present here. It would avoid a lot of misunderstandings. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 29 Jul 2008 at 7:03, Tyler Turner wrote: The problem is that many people were using staff lists for situations where drag-apply really is much smarter. Then there is likely a user interface flaw that is encouraging them in that direction. This sounds like one of those blaming the users situations, where natural user actions lead to behind-the-scenes problems that are most easily avoiding by taking away user choices instead of fixing the underlying behind=the-scenes problem itself. Solving the things the *right* way is really hard. MM doesn't seem interested in doing it right. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 04:27 PM 7/29/2008, David W. Fenton wrote: On 29 Jul 2008 at 7:03, Tyler Turner wrote: The problem is that many people were using staff lists for situations where drag-apply really is much smarter. Then there is likely a user interface flaw that is encouraging them in that direction. This sounds like one of those blaming the users situations, where natural user actions lead to behind-the-scenes problems that are most easily avoiding by taking away user choices instead of fixing the underlying behind=the-scenes problem itself. Solving the things the *right* way is really hard. MM doesn't seem interested in doing it right. David, drag-apply for expressions didn't exist until Fin2009. Tyler's point is that people were using staff lists in a situation where drag-apply would make more sense, *if it existed*. Now it exists, so (in Makemusic's view) staff lists are less necessary. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
The irony is that MM has largely fixed the problem in the right way. They just gilded the lily by adding an arbitrary limit. On Tue, Jul 29, 2008 at 3:27 PM, David W. Fenton [EMAIL PROTECTED] wrote: This sounds like one of those blaming the users situations, where natural user actions lead to behind-the-scenes problems that are most easily avoiding by taking away user choices instead of fixing the underlying behind=the-scenes problem itself. Solving the things the *right* way is really hard. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 29 Jul 2008 at 16:43, Aaron Sherber wrote: At 04:27 PM 7/29/2008, David W. Fenton wrote: On 29 Jul 2008 at 7:03, Tyler Turner wrote: The problem is that many people were using staff lists for situations where drag-apply really is much smarter. Then there is likely a user interface flaw that is encouraging them in that direction. This sounds like one of those blaming the users situations, where natural user actions lead to behind-the-scenes problems that are most easily avoiding by taking away user choices instead of fixing the underlying behind=the-scenes problem itself. Solving the things the *right* way is really hard. MM doesn't seem interested in doing it right. David, drag-apply for expressions didn't exist until Fin2009. Tyler's point is that people were using staff lists in a situation where drag-apply would make more sense, *if it existed*. Now it exists, so (in Makemusic's view) staff lists are less necessary. If they are right, why wouldn't the problem take care of itself? Why cripple the old way in order to force people to use the new way? -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I guess I've changed my mind again. FinMac 2K2 was an almost perfect program. All subsequent versions have been distinctly inferior, and MakeMusic seems to have made almost no effort to restore the smooth, seamless operation of its last pre-OSX version, but has rather introduced new features (notably linked parts) that are buggy, clumsy, incomplete, and logically arbitrary. I only ever bought 2K4 in order to run the program in OSX. If somebody could manage to port 2K2 seamlessly into OSX, I would get it in a heartbeat and never look back. Like many other of the older list members, I have routines I like that I worked out long ago, that work fine for me, and that I have no desire to supplant. I always work in Speedy, for example. I have never used mirrors, because they offer too many chances for user error, and I now realize that, for the same reason, I will never use linked parts. That being so, what use will 2K9 be to me? Precious little, it seems, and I am now resolved to uprgrade beyond 2K7 only if and when my composers become unable to send me materials in a form I can currently work with. Andrew Stiller Kallisti Music Press http://www.kallistimusic.com/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I agree Fin2k2 was good, but many of the subsequent enhancements are one I could not live without (esp. auto-positioning of expressions and, yes, linked parts.) I think those who denigrate linked parts are missing the point. Of course linked parts is only partially implemented, but the question is whether that partial implementation is valuable on its own terms. Is it viable to have a single document containing both score and parts? The answer is usually a resounding NO. But what is completely viable, even easy, is to have one document for your score and another document for *all* parts. This is so self-evidently a vast improvement over the situation that obtained before that I wonder why it seems continually necessary to justify it. Just to cite a few reasons: 1. If I need to change the File Info (title, copyright date, edition number, etc.) I now need to modify only 2 files instead of umpteen. 2. Same for any common text that typically appears on Page 1. 3. I easily can print all parts at once. (Or generate separate PDFs for all parts at once.) 4. Creating cues is MUCH easier with all the parts in one file. 5. Same for making revisions. Even substantial revisions, such as adding or removing bars, go much faster with all the parts in one file. Yes, you still must separately edit all the page layouts for each part, but everything else about it goes faster. If your Mac still supports Classic, I don't know why you can't run Fin2K now. As you move into the Mac Intel or Leopard world, your best option will be SheepShaver. SheepShaver will probably run Fin2K as well as Classic does, perhaps better in some ways. But printing from SheepShaver is not pretty, and I have no idea if SheepShaver supports MIDI. My guess is, not easily. On Mon, Jul 28, 2008 at 10:13 AM, Andrew Stiller [EMAIL PROTECTED] wrote: I guess I've changed my mind again. FinMac 2K2 was an almost perfect program. All subsequent versions have been distinctly inferior, and MakeMusic seems to have made almost no effort to restore the smooth, seamless operation of its last pre-OSX version, but has rather introduced new features (notably linked parts) that are buggy, clumsy, incomplete, and logically arbitrary. I only ever bought 2K4 in order to run the program in OSX. If somebody could manage to port 2K2 seamlessly into OSX, I would get it in a heartbeat and never look back. Like many other of the older list members, I have routines I like that I worked out long ago, that work fine for me, and that I have no desire to supplant. I always work in Speedy, for example. I have never used mirrors, because they offer too many chances for user error, and I now realize that, for the same reason, I will never use linked parts. That being so, what use will 2K9 be to me? Precious little, it seems, and I am now resolved to uprgrade beyond 2K7 only if and when my composers become unable to send me materials in a form I can currently work with. Andrew Stiller Kallisti Music Press http://www.kallistimusic.com/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Some comments re Fin09
Why do you have 50 staff lists? What causes you to need that many? This is not a rhetorical question, I'm genuinely interested. I just did a brand new full score in Finale 2009 and only used ONE (that's right) one staff list. Robert also forgot to mention that you can now drag-apply expressions. While this caused me to change my workflow, it also mitigated my need for most staff lists. Allen J. Fisher MakeMusic [EMAIL PROTECTED] www.finalemusic.com From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Claudio Pompili [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:22 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Some comments re Fin09
And remember, I don't appear here in any official capacity. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:55 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Strangely, Mr. Fisher who was quick to jump on the Speedy Entry was dropped rumor is no where to be found. I don't get why would do that On Fri, Jul 25, 2008 at 7:22 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Andrew: This isn't meant to counter your position... But you can extract parts in 2K9. I work with linked parts until I get them close, then extract and tweak. I rather like the option because occasionally I get a part that works as linked and I can just print it without extra tweaking. -Carolyn On Mon, Jul 28, 2008 at 8:13 AM, Andrew Stiller [EMAIL PROTECTED] wrote: I guess I've changed my mind again. FinMac 2K2 was an almost perfect program. All subsequent versions have been distinctly inferior, and MakeMusic seems to have made almost no effort to restore the smooth, seamless operation of its last pre-OSX version, but has rather introduced new features (notably linked parts) that are buggy, clumsy, incomplete, and logically arbitrary. I only ever bought 2K4 in order to run the program in OSX. If somebody could manage to port 2K2 seamlessly into OSX, I would get it in a heartbeat and never look back. Like many other of the older list members, I have routines I like that I worked out long ago, that work fine for me, and that I have no desire to supplant. I always work in Speedy, for example. I have never used mirrors, because they offer too many chances for user error, and I now realize that, for the same reason, I will never use linked parts. That being so, what use will 2K9 be to me? Precious little, it seems, and I am now resolved to uprgrade beyond 2K7 only if and when my composers become unable to send me materials in a form I can currently work with. Andrew Stiller Kallisti Music Press http://www.kallistimusic.com/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Some comments re Fin09
God forbid I take a day off. Sheesh. Allen J. Fisher MakeMusic [EMAIL PROTECTED] www.finalemusic.com From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:55 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Strangely, Mr. Fisher who was quick to jump on the Speedy Entry was dropped rumor is no where to be found. I don't get why would do that On Fri, Jul 25, 2008 at 7:22 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. On Mon, Jul 28, 2008 at 8:54 AM, Fisher, Allen [EMAIL PROTECTED]wrote: And remember, I don't appear here in any official capacity. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:55 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Strangely, Mr. Fisher who was quick to jump on the Speedy Entry was dropped rumor is no where to be found. I don't get why would do that On Fri, Jul 25, 2008 at 7:22 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Thanks Tyler, That is the solution, even if, for me, it isn't as convenient as having more staff lists available. But at least it does work. Bernard On Jul 28, 2008, at 12:27, [EMAIL PROTECTED] wrote: No, I don't think that would be the fastest way. I would think you'd do this - from the score, drag apply the expression to all staves you want it on in the parts, all at once (using a metatool if you have one). Then drag select the handles of the ones you don't want visible in the score and press ctrl-alt-shift-U and then ctrl-alt-shift-H. That unlinks them and then hides them only in the score. Tyler ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 12:38 PM 7/28/2008, Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. Oh, come on now. This point has been made a gazillion times, and it still bugs me to see it. Makemusic runs two in-house support channels. They have a public forum, and they have a site for individual support cases. This list was started by a regular Finale user, for the benefit of other Finale users, and has no connection to Makemusic. MM has several employees who subscribe to the list, and a few who chime in now and then, but they're not here as part of their jobs. I think it's admirable that Sibelius puts reps on third-party listservs, and I agree that it would be nice if Finale did the same. But I have a hard time actively faulting them for not doing so. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 28.07.2008 Fisher, Allen wrote: And remember, I don't appear here in any official capacity. I and many others know that. It is nice that you are here, it would be even nicer if MM did actually send an official representative to monitor the list. But it is not your fault that they don't and we really appreciate your presence. However, perhaps you could pass on to whoever it might concern, that a lot of long-time Finale users get the feeling more and more, that they are not really cared about much at MM. Johannes PS I do feel that this non-official capacity it sort of false, as surely you are not completely free to express your personal opinions here. Not even beta-testers are, in that respect. So why not make it official? Sibelius does seem to have much better communication with their user base, and one reason for that is that they officially listen. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
So, you figure the best way to get what you want is to dump all over Allen Fisher for volunteering his time here? - Darcy - [EMAIL PROTECTED] Brooklyn, NY On 28 Jul 2008, at 12:38 PM, Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. On Mon, Jul 28, 2008 at 8:54 AM, Fisher, Allen [EMAIL PROTECTED]wrote: And remember, I don't appear here in any official capacity. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:55 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Strangely, Mr. Fisher who was quick to jump on the Speedy Entry was dropped rumor is no where to be found. I don't get why would do that On Fri, Jul 25, 2008 at 7:22 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
It seems funny that the man puts his MakeMusic info at the bottom and is not here officially. Why not just have an official presence here and handle the questions and complaints? Heck, seeing Daniel on the Sibelius list, I think that MakeMusic could do a lot for it's image and keeping it's user base happy if they would. Just seems kind of half assed. On Mon, Jul 28, 2008 at 10:18 AM, Darcy James Argue [EMAIL PROTECTED] wrote: So, you figure the best way to get what you want is to dump all over Allen Fisher for volunteering his time here? - Darcy - [EMAIL PROTECTED] Brooklyn, NY On 28 Jul 2008, at 12:38 PM, Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. On Mon, Jul 28, 2008 at 8:54 AM, Fisher, Allen [EMAIL PROTECTED] wrote: And remember, I don't appear here in any official capacity. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:55 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Strangely, Mr. Fisher who was quick to jump on the Speedy Entry was dropped rumor is no where to be found. I don't get why would do that On Fri, Jul 25, 2008 at 7:22 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. Fisher, Allen [EMAIL PROTECTED]wrote: And remember, I don't appear here in any official capacity. Come on! Let's not chase away all our valuable contributors. I appreciate Allen Fisher's presence here and I don't think I'm alone in this. -Randolph Peters ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
I'm not saying that at all. I'm saying it is like a game or something. They are here, but they aren't Officially on the list. Stupid. If you are going to put your MakeMusic company thing at the end of your emails then you should be on here officially. Again, I think if we could get MakeMusic and it's list monitors to stop this game it would be good. How hard would it be to have someone field the questions in an official manner? I'm sure that no one expects the kind of question answering that Daniel does on Sibelius's behalf, but some sort of effort would be nice. On Mon, Jul 28, 2008 at 10:37 AM, Randolph Peters [EMAIL PROTECTED]wrote: Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. Fisher, Allen [EMAIL PROTECTED]wrote: And remember, I don't appear here in any official capacity. Come on! Let's not chase away all our valuable contributors. I appreciate Allen Fisher's presence here and I don't think I'm alone in this. -Randolph Peters ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 28.07.2008 Eric Dannewitz wrote: I'm not saying that at all. I'm saying it is like a game or something. They are here, but they aren't Officially on the list. Stupid. If you are going to put your MakeMusic company thing at the end of your emails then you should be on here officially. I have to agree. Again, I think if we could get MakeMusic and it's list monitors to stop this game it would be good. How hard would it be to have someone field the questions in an official manner? I'm sure that no one expects the kind of question answering that Daniel does on Sibelius's behalf, but some sort of effort would be nice. Actually, that's exactly what we have to expect. If Finale is trying to be better than Sibelius, it should start with the user support, and the communications with its user base. If it cannot even manage to beat Sibelius in that field, I don't see how it can win at all. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Fisher, Allen wrote: And remember, I don't appear here in any official capacity. And while I think less of MM for not officially endorsing it, I think very highly of you as a person and as a MM employee who is willing to enter the fray to help both the user and the company come to some sort of mutual understanding and to take the time to help us understand things about the program better. Thank you, Allen, for spending the time that you do spend on this list! -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. The other company DOES have someone do that -- Daniel Spreadbury, senior products manager or some such position, is an official member (and quite helpful) member of the Sibelius group at yahoogroups.com. Allen is all the more to be admired for maintaining his presence on this list, as was Randy many years ago. It takes time to read these posts, wade through them all and decide which ones will benefit from a response by a known MM employee, even if unofficially, and offer help and insights. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Yes, I know that Daniel does an excellent job on and off the Sibelius list. I think that MakeMusic not bothering to have an official person on a list is something that should be addressed. If not this list, a yahoogroup one or something. On Mon, Jul 28, 2008 at 11:28 AM, dhbailey [EMAIL PROTECTED] wrote: Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. The other company DOES have someone do that -- Daniel Spreadbury, senior products manager or some such position, is an official member (and quite helpful) member of the Sibelius group at yahoogroups.com. Allen is all the more to be admired for maintaining his presence on this list, as was Randy many years ago. It takes time to read these posts, wade through them all and decide which ones will benefit from a response by a known MM employee, even if unofficially, and offer help and insights. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Eric Dannewitz wrote: [snip] How hard would it be to have someone field the questions in an official manner? I'm sure that no one expects the kind of question answering that Daniel does on Sibelius's behalf, but some sort of effort would be nice. As much as I would love to have a reliable and quick way to deal with my Finale concerns, I think it would be quite an investment to have someone field questions in an official manner. I could easily see this requiring a full-time job (or several). I know we are worth it! But from a business point of view, I'm not so sure. Besides, I'm sure MM considers their tech support and their forum to serve in this way. A (polite) case can be made that these services need improving, but that's a different argument. -Randolph Peters ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Jul 28, 2008, at 10:37 AM, Randolph Peters wrote: Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. Fisher, Allen [EMAIL PROTECTED]wrote: And remember, I don't appear here in any official capacity. Come on! Let's not chase away all our valuable contributors. I appreciate Allen Fisher's presence here and I don't think I'm alone in this. -Randolph Peters My sentiments too. Chuck ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Chuck Israels 230 North Garden Terrace Bellingham, WA 98225-5836 phone (360) 671-3402 fax (360) 676-6055 www.chuckisraels.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
So why not have one of the tech support people actually do this? They could also use discussions as a basis of a wiki or knowledge base. Plus, the perceived good PR couldn't hurt. On Mon, Jul 28, 2008 at 11:30 AM, Randolph Peters [EMAIL PROTECTED]wrote: As much as I would love to have a reliable and quick way to deal with my Finale concerns, I think it would be quite an investment to have someone field questions in an official manner. I could easily see this requiring a full-time job (or several). I know we are worth it! But from a business point of view, I'm not so sure. Besides, I'm sure MM considers their tech support and their forum to serve in this way. A (polite) case can be made that these services need improving, but that's a different argument. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Some comments re Fin09
Actually that's my fault. I normally do not include my signature at the bottom of my posts. My email prefs got blown away and I've now reset them. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Dannewitz Sent: Monday, July 28, 2008 12:28 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 It seems funny that the man puts his MakeMusic info at the bottom and is not here officially. Why not just have an official presence here and handle the questions and complaints? Heck, seeing Daniel on the Sibelius list, I think that MakeMusic could do a lot for it's image and keeping it's user base happy if they would. Just seems kind of half assed. On Mon, Jul 28, 2008 at 10:18 AM, Darcy James Argue [EMAIL PROTECTED] wrote: So, you figure the best way to get what you want is to dump all over Allen Fisher for volunteering his time here? - Darcy - [EMAIL PROTECTED] Brooklyn, NY On 28 Jul 2008, at 12:38 PM, Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. On Mon, Jul 28, 2008 at 8:54 AM, Fisher, Allen [EMAIL PROTECTED] wrote: And remember, I don't appear here in any official capacity. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:55 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Strangely, Mr. Fisher who was quick to jump on the Speedy Entry was dropped rumor is no where to be found. I don't get why would do that On Fri, Jul 25, 2008 at 7:22 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Still think you should strongly suggest to your employer that you be allowed to answer questions on this list (and perhaps others) in an official manner. Why not spend 30 minutes or so fielding questions (or someone fielding questions) rather than this we are here, but unofficially thing. Sibelius does it. MakeMusic seems to be copying Sibelius in everything else.,.,, On Mon, Jul 28, 2008 at 12:54 PM, Fisher, Allen [EMAIL PROTECTED]wrote: Actually that's my fault. I normally do not include my signature at the bottom of my posts. My email prefs got blown away and I've now reset them. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Dannewitz Sent: Monday, July 28, 2008 12:28 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 It seems funny that the man puts his MakeMusic info at the bottom and is not here officially. Why not just have an official presence here and handle the questions and complaints? Heck, seeing Daniel on the Sibelius list, I think that MakeMusic could do a lot for it's image and keeping it's user base happy if they would. Just seems kind of half assed. On Mon, Jul 28, 2008 at 10:18 AM, Darcy James Argue [EMAIL PROTECTED] wrote: So, you figure the best way to get what you want is to dump all over Allen Fisher for volunteering his time here? - Darcy - [EMAIL PROTECTED] Brooklyn, NY On 28 Jul 2008, at 12:38 PM, Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. On Mon, Jul 28, 2008 at 8:54 AM, Fisher, Allen [EMAIL PROTECTED] wrote: And remember, I don't appear here in any official capacity. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Eric Dannewitz [EMAIL PROTECTED] Sent: Friday, July 25, 2008 09:55 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Strangely, Mr. Fisher who was quick to jump on the Speedy Entry was dropped rumor is no where to be found. I don't get why would do that On Fri, Jul 25, 2008 at 7:22 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 12:00 -0500 25/7/08, [EMAIL PROTECTED] wrote: Date: Fri, 25 Jul 2008 10:45:53 -0500 From: Robert Patterson [EMAIL PROTECTED] Subject: Re: [Finale] Some comments re Fin09 If you made extensive, purposeful use of Staff Lists, you can kiss all that goodbye. When your files are imported, each instance on each staff will become unlinked. The Fin2k9 limit of 4 Staff Lists is REALLY BAD news for me. Many pieces have upwards of 50 or more staff lists and this is a killer for me. Other worries for me are the new beat-placement expressions when importing older works with V1/V2. Still, Fin2k9 is looking like a really worthwhile upgrade but I don't understand MM's logic in placing such an arbitrary limit on the SL function. The other improvements especially the Expression categories have been a long time coming and commendable. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Some comments re Fin09
Just so everyone knows, the demo is available (we worked hard to turn that around quicker this year...) so that you can try out the new expressions. My (take it as you will) opinion is that the new expressions are far better than the old ones. I also do not use staff lists to the extent of some folks here, but I think when you see what we're looking to accomplish I think you'll like the change. I also did a bunch of work with old files from back when I didn't know finale as well while I was gone a couple of weeks ago. It did not take me long at all to get all the expressions working with the new stuff. I just dropped them into categories, reset the fonts and positioning, and shaved a LOT of cleanup work off the conversion (I think they were Fin97 files...). That said, since I've distracted everyone from discussing Finale by accidentally including my signature and taking a vacation day, I think it's best that I shut up for a while. We do, as Aaron mentioned two official routes for support: our forum (http://forum.makemusic.com/) and our Knowledge Base/Case System (http://www.finalemusic.com/support.aspx). The KB is not static like the old FAQ's used to be, and is constantly updated based on what users are contacting us most about. I've always viewed this list as a place where Finale users could discuss their techniques, things they've learned, engraving standards, fun topics about the millennium changing, etc; not as a conduit to MakeMusic. I've been on this list for close to 10 years, and I seem to remember statements in the past that one of the reasons people subscribed to this list was that there was no official corporate presence here, and that their opinions could be expressed more freely. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dhbailey Sent: Monday, July 28, 2008 1:29 PM To: finale@shsu.edu Subject: Re: [Finale] Some comments re Fin09 Eric Dannewitz wrote: This is true. Heaven forbid that MakeMusic would allow that. That would be doing something like supporting the program. I think only that other company, Sibelius, actually would have someone do that. The other company DOES have someone do that -- Daniel Spreadbury, senior products manager or some such position, is an official member (and quite helpful) member of the Sibelius group at yahoogroups.com. Allen is all the more to be admired for maintaining his presence on this list, as was Randy many years ago. It takes time to read these posts, wade through them all and decide which ones will benefit from a response by a known MM employee, even if unofficially, and offer help and insights. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Fisher, Allen wrote: Robert also forgot to mention that you can now drag-apply expressions. While this caused me to change my workflow, it also mitigated my need for most staff lists. Actually, I believe I did mention it. I just didn't make a big deal about it. MM seems to think this can make up for 90% of the times people used to use Staff Lists, but I think MM is mistaken. I am very grateful for the addition of drag-apply. Just as it wsa for Articulations, it will be very useful. But I see it as a very poor substitute for Staff Lists. Why? 1. It takes several more steps than applying an expression with staff list (which could be a single click with a metatool). 2. I tend to work with scores from templates that do not have the parts already created. Thus the normal hide/show doesn't really work for me in this case. And the new Part Only assignment option has to be set one assignment at a time thru dlg boxes. 3. The normal hide/show clutters up the view with ghost images of the hidden assignments. Especially for something like what Claudio does it would be a massive step backwards from Staff Lists. 4. It is not easy to come back later and move all instances at once. I especially like the way Fin09 handles group vs. individual movement for Staff Lists, so it is particularly annoying that Staff Lists in Fin09 are so limited. 5. There is no way to easily change all occurrences. For example, if I have a String Section Staff List, it is easy to go back and fix all assignments with that staff list if I add a new staff to the string section. Drag-apply in this scenario requires highly error-prone re-editing. I actually think the new implementation of Staff Lists as part of the definition of the expression (thru the category) rather than the assignment is an incentive for those of us who use them purposefully to use them more, not less. It makes them easier to find, understand, and less likely to be used without a reason. -- Robert Patterson http://RobertGPatterson.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Thanks Tyler for the suggestion of using the new 'drag expressions' to deal with the crippling of Staff Lists in 2k9. It's not going to be anywhere near as convenient and efficient. I'm in the same boat as Bernard Savoie and others who have made extensive use of SLs and I'll probably have to have 'pre-2k9' and 'post 2k9' files littered around my HDs, like it's not enough to have to keep practically every version of the Finale apps that came out so as to access older files without updating them. I posted MM and got the following reply: At 10:05 -0500 28/7/08, MakeMusic Customer Support wrote: The decision to limit Finale 2009 to 4 staff groups was done after much testing and work with clinicians. We will be limiting Finale 2009 to 4 groups at this time, but I will put in your request for changes to be made to later versions. I won't hold my breath. What I find sad about this is the mindset/culture at MM, yet again. Testing with clinicians is fine but when contemplating scaling back a feature such as SLs that have been around for a while, wouldn't it have made sense to run it past a bigger group of users apart from the people who you have on your books as clinicians, undoubtedly very knowledgeable about Finale? I mean to say, how hard would it have been to have posted on this list and the official MM forums an innocuous line like, 'hey, anybody out there using SLs?' (from a 'lurker' email address or an anonymous remailer if MM were paranoid about commercial-in-confidence issues). I understand that MM might not want to be beholden to this or any other community of users; but instead of seeing this particular and important, long-time community of Finale users as part of the solution, with its broad base from amateurs to pros and international perspectives, the group is ignored and treated like an 'other', ie the enemy. shame because other aspects of Finale in recent years such as linked parts and now upgrades to expressions, resizable dialogs (although poorly implemented), scripts and aria/vst playback features are very worthwhile. I'm not averse to change, however, it doesn't auger well for other long-time features of Finale like Speedy entry (pitch before duration) that I've used exclusively since v.1.x and the powerful but lamentably-dated Shape Designer. -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On Mon, Jul 28, 2008 at 7:36 PM, Claudio Pompili [EMAIL PROTECTED] wrote: At 10:05 -0500 28/7/08, MakeMusic Customer Support wrote: The decision to limit Finale 2009 to 4 staff groups was done after much testing and work with clinicians. We will be limiting Finale 2009 to 4 groups at this time, Is that not classic Finn-brothers speak? Oh, we know better how to use this program than you do. Why would you want to do that? No music *we've* ever thought of could possibly need that feature. Doing that would be wrong. Never mind that Claudio has probably been using the dang program longer than any of them or their vaunted clinicians have. (I'm guessing he's an old v1.0 hack like me.) What augers worst for me in this attitude is the clear Sibeliusation trend. Sibelius always took knocks because it wasn't as flexible as Finale. When the Finn brothers were in charge Sib was willfully inflexible. Now MM seems to want to throw away their competitive edge with both hands and embrace the Finn brothers' ideas about flexibility. I have no idea who these clinicians were, but if they were like every other consultant I know of, then their job was to make sure they told their client what the client wanted to hear. The client obviously wanted hear that 4 SLs was enough. I wish MM would just be honest and admit that this limit is an arbitrary shortcut to get the product out the door. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 08:36 PM 7/28/2008, Claudio Pompili wrote: What I find sad about this is the mindset/culture at MM, yet again. Testing with clinicians is fine but when contemplating scaling back a feature such as SLs that have been around for a while, wouldn't it have made sense to run it past a bigger group of users apart from the people who you have on your books as clinicians, undoubtedly very knowledgeable about Finale? Apropos of this: http://www.37signals.com/svn/posts/1118-features-are-a-one-way-street Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
--- On Mon, 7/28/08, Robert Patterson [EMAIL PROTECTED] wrote: What augers worst for me in this attitude is the clear Sibeliusation trend. Sibelius always took knocks because it wasn't as flexible as Finale. When the Finn brothers were in charge Sib was willfully inflexible. Now MM seems to want to throw away their competitive edge with both hands and embrace the Finn brothers' ideas about flexibility. Sibelius' lack of flexibility is really the thing that allowed it to survive and make it in this market. Flexibility only works in Finale's favor if the implementation always makes it clear what the BEST method is in a given situation. And that is the single largest problem Finale has faced all along. Finale's flexibility is really only attractive to a fairly small (but important) percentage of its users - for the rest, it has served as a stumbling block that makes the program take longer to learn and slower to use. Inevitably, people end up using less than ideal tools for completing their work in Finale, and that goes for people of all experience levels. I've never seen anyone who truly uses the best tool for the job in Finale 100% of the time. Sibelius isn't perfect that way, but having fewer ways to accomplish most tasks has definitely helped them funnel people into techniques that are often more effective than the ones people stumble upon in Finale. Sibelius' lack of flexibility (especially early on) may have given it a slow start with engravers, but it was exactly the thing that brought it success with college students and other new users that join the market each year. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Hi Tyler, 100% agreed. Feature bloat has long been a problem in Finale. Most of their streamlining choices over the years have been good ones (merging Note Expressions and Staff Expressions into a single Expression tool, replacing the Mass Mover tool with the Mass Edit tool, then merging the Section Tool with Mass Edit, etc.) -- although as the article Aaron linked observed, this kind of consolidation is extremely difficult, as users get set in their ways. That said, limiting users to four staff lists is a *terrible* idea. I understand the impulse behind it, as it's much better to try to push users towards drag-enclose expressions. (I still get sent a lot of scores where all the dynamics are measure-attached, and they are always a nightmare to fix, even with TGTools). But there are was to do that that don't involve taking away staff lists. Cheers, - Darcy - [EMAIL PROTECTED] Brooklyn, NY On 29 Jul 2008, at 12:26 AM, Tyler Turner wrote: --- On Mon, 7/28/08, Robert Patterson [EMAIL PROTECTED] wrote: What augers worst for me in this attitude is the clear Sibeliusation trend. Sibelius always took knocks because it wasn't as flexible as Finale. When the Finn brothers were in charge Sib was willfully inflexible. Now MM seems to want to throw away their competitive edge with both hands and embrace the Finn brothers' ideas about flexibility. Sibelius' lack of flexibility is really the thing that allowed it to survive and make it in this market. Flexibility only works in Finale's favor if the implementation always makes it clear what the BEST method is in a given situation. And that is the single largest problem Finale has faced all along. Finale's flexibility is really only attractive to a fairly small (but important) percentage of its users - for the rest, it has served as a stumbling block that makes the program take longer to learn and slower to use. Inevitably, people end up using less than ideal tools for completing their work in Finale, and that goes for people of all experience levels. I've never seen anyone who truly uses the best tool for the job in Finale 100% of the time. Sibelius isn't perfect that way, but having fewer ways to accomplish most tasks has definitely helped them funnel people into techniques that are often more effective than the ones people stumble upon in Finale. Sibelius' lack of flexibility (especially early on) may have given it a slow start with engravers, but it was exactly the thing that brought it success with college students and other new users that join the market each year. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
This limited staff list is a real bummer for me. I just finished a contemporary score for full orchestra where the composer had a lot of performance explanations, often several lines long) for individual instrument groups. To show these indications on all the relevant staves in a score is really not practical. So if I need to indicate an explanation for, say all the clarinets (4 in this case), I use a staff list to define a view on the 1st clarinet in the score and on each individual parts. Now repeat the same scenario with all the strings, all the violins (I II), all the trumpets, all the trombones, all the horns, all the brass, all the woodwinds, all the flutes... Well, you get the idea. Four staff lists really won't cut it. The only way I will be able to deal with this scenario in 09, it seams, will be to duplicate the file once the score is finished and copy the indications to the pertinent parts for individual parts. This is a giant step backwards. Looks like I'll be evaluating using '09 on a case per case basis. If I think I won't be needing so many staff list, then fine. Otherwise, I'll stick with an earlier version. By the way, they have kept the ability to create multiple staff lists as far as repeats go. Go figure. Bernard Savoie On Jul 26, 2008, at 13:00, Robert Patterson wrote: This does not mean I think MM is justified, but I understand their reasons. That said, in the Fin09 world it is difficult for me to see how you would need 50 Staff Lists. You would have to have more than 50 expression categories, which would just confuse the heck out of me. Nevertheless, just because I can't think of reason you should need 50 SLs is no reason for you not to need them. I'd be interested to know what drives you to use that many. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 10:43 AM 7/27/2008, Bernard Savoie wrote: This limited staff list is a real bummer for me. I just finished a contemporary score for full orchestra where the composer had a lot of performance explanations, often several lines long) for individual instrument groups. To show these indications on all the relevant staves in a score is really not practical. So if I need to indicate an explanation for, say all the clarinets (4 in this case), I use a staff list to define a view on the 1st clarinet in the score and on each individual parts. The only way I will be able to deal with this scenario in 09, it seams, will be to duplicate the file once the score is finished and copy the indications to the pertinent parts for individual parts. You could also attach the expression to each of the 4 clarinet staves, and then hide it in the score for clarinets 2-4. I agree that this may not be as simple as a staff list, but it seems easier than the alternate method you describe. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
--- On Sun, 7/27/08, Bernard Savoie [EMAIL PROTECTED] wrote: So if I need to indicate an explanation for, say all the clarinets (4 in this case), I use a staff list to define a view on the 1st clarinet in the score and on each individual parts. Now repeat the same scenario with all the strings, all the violins (I II), all the trumpets, all the trombones, all the horns, all the brass, all the woodwinds, all the flutes... Well, you get the idea. Four staff lists really won't cut it. The only way I will be able to deal with this scenario in 09, it seams, will be to duplicate the file once the score is finished and copy the indications to the pertinent parts for individual parts. This is a giant step backwards. Looks like I'll be evaluating using '09 on a case per case basis. If I think I won't be needing so many staff list, then fine. Otherwise, I'll stick with an earlier version. No, I don't think that would be the fastest way. I would think you'd do this - from the score, drag apply the expression to all staves you want it on in the parts, all at once (using a metatool if you have one). Then drag select the handles of the ones you don't want visible in the score and press ctrl-alt-shift-U and then ctrl-alt-shift-H. That unlinks them and then hides them only in the score. Tyler ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
this is regarding Fin2k9's limit of 4 Staff Lists At 12:00 -0500 26/7/08, Robert Patterson wrote: Claudio Pompili wrote: I don't understand MM's logic in placing such an arbitrary limit on the SL function. snip that said, in the Fin09 world it is difficult for me to see how you would need 50 Staff Lists. You would have to have more than 50 expression categories, which would just confuse the heck out of me. Nevertheless, just because I can't think of reason you should need 50 SLs is no reason for you not to need them. I'd be interested to know what drives you to use that many. I use lots of Staff Lists particularly in long, multi-movement works eg music-theatre. One piece that requires a lot of performer improvisation, immediately comes to mind is where I've got 10 vocalists doubling as soloists and chorus with a small instrumental group of clars/vc/percussion (large array of perc. organised into three distrinct groups eg Latin, drum kit, and orchestral perc). For the most part, the notation uses a lot of unmeasured bars and timelines above the staves as visual/approx. indicators. Many sections have ritornelli ad libitum in the style of Lutoslawski. The conductor gives sectional cues ( up/down varieties of arrows and staff expressions) (eg a downbeat to begin a section that might last eg., for approx. 4 minutes; further instrumental cues might be given during the section to indicate to performers' entries/exits. Further, within sections, individual performers might cue each other at particular points in time. Similar cues/entries/exists occur in the vocal parts between and within soloists and chorus etc. To aid the performers, I included such cue marks in the score and more detailed cues between performers/groups in the parts. Many of the different groupings/orchestrations recur during the composition and warranted a systematic way of having sets of expressions that show/hide in the score and parts. To this end I used sets of categories of cues set up as Staff Lists that worked very well, albeit its complexity and that the nomenclature evolved during the course of composition so it's not perfect or pretty but works for me (aided consistency saved time in production of parts etc). For example, Conductor Cue1a (top TL+TLs prts) Conductor Cue2 (TLs+ prts) Conductor Cue3a1 (top TL Scr/Prt+Sop1 Scr/Prt) Conductor Cue3a2 (top TL Sc/Prt+Sop1 Prt) Conductor Cue3b (top TL+Sop2) Conductor Cue3c (top TL+Alto1) Conductor Cue3d (top TL+Bar1) Conductor Cue3e (top TL+Bass1) ...to Conductor Cue12.16b(top TL+TL Inst.Grp/Perc1/2) OR for the 3 perc groups Perc1.1(TL+staves Scr+Prts) Perc1.2(staves Scr+Prts) Perc2.1(TL+staves Scr+Prts) Perc2.2(staves Scr+Prts) Perc3.1(top 2 staves) Perc3.2(bot 3 staves) OR for vocalists/chorus Chorus1a (Sop ,MS Bar Scr+Prts) Chorus1b (Sop Scr+Prts,MS Bar Prts) Chorus1c (Sop4 Scr+Prt) (I've put a small GIF of a typical system at http://www.claudiopompili.net.au/FinMac2k8b_TW_PIIS4p1701.gif where you can see the conductor cues indicating entries/exists in the full score, which is fairly sparse in visual terms) I'll be sending a request to MM for reinstatement of unlimited SLs and keep my fingers x'ed -- cheers, Claudio Claudio Pompili composer, sound designer, music consultant http://www.claudiopompili.net.au/ (**2002-2003 Golden Web Award**) Skype: claudiop_509 Australian Music Centre http://www.amcoz.com.au; http://www.amcoz.com.au/composers/composer.asp?id=236 ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 26.07.2008 Matthew Hindson fastmail acct wrote: The worst thing seems to be that I will have to upgrade to Finale 09 to fix the @[EMAIL PROTECTED] non-WYSIWYG slurs, but lose features in the process. I've just about had it with Finale. If only Sibelius had a means by which one could select pitch then rhythm when entering notes, I would change over (and join the rest of Australia in the process). Well, at least as far as the slurs are concerned, all you have to do is switch off Engraver slurs and you have what Sibelius has in this area, and no Engraver slur bugs. However, this is actually what is stopping me, I like Engraver slurs, as they save me time. 2k9 may be an incredible time saver for me if the bugs are gone. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 26.07.2008 Robert Patterson wrote: Why would you want to do that? was ever the mantra of the foolish 2nd-guesser. Wasn't that the Sibelius philosophy some time ago? Now they have swapped over? Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Robert Patterson wrote: As near as I can tell, there is no artificial limit in the data structures. I have not tried it, but I know how (datawise) to make a plugin add more. (That doesn't mean a plugin should do it, of course. The resulting file would be completely unsupported.) Why the limit? Honestly I think it is because the designers at MM could not imagine a reason you might want more. Why would you want to do that? was ever the mantra of the foolish 2nd-guesser. If that were the reason, why wasn't the limit of 4 staff lists applied years ago? I don't think they sat around the development table discussing what would go into this version and someone said Oh, yeah, and we really have to cut our staff list possibilities down to four. Now just because I can't imagine them discussing it in that manner doesn't mean that's not the way it happened. But it really worries me when what used to be a very flexible tool for anybody who wanted to use it has been so severely restricted. If it truly is because they decided we shouldn't want more than four staff lists, then that is a horrible precedent -- what will they decide we shouldn't want next? -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
Johannes Gebauer wrote: On 26.07.2008 Robert Patterson wrote: Why would you want to do that? was ever the mantra of the foolish 2nd-guesser. Wasn't that the Sibelius philosophy some time ago? Now they have swapped over? Johannes It appears that is the case. Sibelius started with that philosophy (or if not stated as such, that was the result) but as their user base grew and as more professional engravers have added Sibelius to their toolbox, they appear to have adopted a lot more of we're not sure why you'd want to do that, but since a lot of you want to, we'll do our best to work it into the program. It has been a very interesting thing to observe over the years, Finale's transition from anything possible in notation we'll work hard to enable in Finale if we can to We really think this is how you should do things while Sibelius has gone from Why would you want to do that to we'll see if that's possible. And the programs have gone from Sibelius v3, where I bought the program, being very difficult for me to begin to use to v5, which I have found a delight to work with, and Finale has gone from a program where I felt very comfortable and could do anything I wanted to fairly easily to a program which I am finding more and more uncomfortable to use. Of course, I haven't remained unchanged either, and it could just be me who has done the changing while the programs (and companies) have maintained more stability in their courses and their purposes than I realize. :-) I readily admit that. I still fire up Finale immediately when I need to do something quick for my students, and I fire up Sibelius when I need to something a lot more involved. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Some comments re Fin09
Robert is certainly spot-on in his comments, and please allow me to add a few points from the playback and miscellaneous areas. *Finalescript 2.0 is better than ever. If you are not an FS user, you ought to be, since it can automate a large number of nuisance repetitive activities. Older versions of FS seemed to be an afterthought, but the 2.0 is well-documented and well-executed. Even if you're convinced you'll never use FS, just do me a favor and check it out!! I use it--among other uses--to make quick transformations between treble euphonium, bass clef euphonium, F Horn, and concert treble parts that I and others use interchangeably. *ASIO Support...this brings Finale into compatibility with modern audio setups on most machines. It lowers latency and reduces sputtering and gagging at playback. If you don't have an ASIO driver on your machine, consider ASIO4ALL (though it can be temperamental) *UNIVERSAL VST Support--you are no longer tethered to Native Instruments VSTs!! Load up any VST library and play away. There's a nice VST manager as well, so it's easy to tell Finale where your VSTs are, thus avoiding needless duplication of DLLs *ARIA player. Very user-friendly and nice sounds from Garritan. WHAT DO I MISS??? That's easy...ABILITY TO RUN PLUGINS ON LINKED PARTS!! For those who inquired about our status after the flood hit, THANKS!! We are recovering slowly but surely...we didn't get hit as bad as some, but we are having to redo our basement, in which we used to spend a lot of time. Jim From: [EMAIL PROTECTED] on behalf of Robert Patterson Sent: Fri 25-Jul-08 9:51 To: Finale Subject: [Finale] Some comments re Fin09 Since Fin09 is making appearances in the wild now, I feel there is no longer any reason not to comment on some of its new features. There are only three items in the upgrade that are of primary interest or concern to a user like me, who is focused entirely on notation and ease-of-use and doesn't care much about playback. 1. They have mitigated problems with engraver slurs. I have not played with this enough to comment on whether they have fully eliminated the problems, but any progress here is to the good. 2. They now allow editing of multiple (consecutive) pages at once in a single window. With today's gigantic flat panels and powerful processors to drive them, it is a huge bonus. 3. They have reinvented Expressions. It is this final feature that I am most familiar with, so I will comment the most about it. The most important thing you need to know as an existing Finale user is NOTE-ATTACHED EXPRESSIONS HAVE BEEN REMOVED. Let that sink in for a minute. Catch your breath. And begin to think of the ramifications. Then before you begin to scream, read on. Instead of note-attached expressions we now have beat-attached expressions. We always have had beat-attached expressions, you might say. And you would be right if by always you mean since v3.0, c. 1994. But these beat-attached expressions are different. They can sense a note that is at that beat and react to it, tracking it movements with the Note Mover, and autopositioning vertically based on the same entry-oriented settings that used to be there for note-attached. This seems really plausible until you start thinking about layers, grace notes, v1/v2, and even tuplets of 0-length. All of these mean that an unlimited number of notes can coincide at the same beat location. Here is one of the really good new things: MM has eliminated the need for all those assignment dialogs. Now you select an expression from the dialog, and it knows how to assign itself. But if you are in the situation of multiple notes coinciding on the beat, you have to open the assignment dialog. There you will find options to select Layer and which (if any) grace note to track. You will NOT find support for separately tracking V1 or V2. I don't see this as a problem for new files, but it could be for existing files. I have adopted note-oriented as my term for these new beat-attached items that have replaced note-attached items. If you assign a note-oriented item to a meaure that has no notes, it behaves just like an old-fashioned beat-attached (meas-attached) expression. Here is the next really good thing. Expressions can now be placed in categories, and every expression in that category can have the same settings. There are (I believe) seven base categories with different settings options, and you can clone those for as many categories as you would like. You can also filter by category (or not) when you select from the dialog to assign one. Now, about those Staff Lists. MM made a mess of Staff Lists with a copying bug they introduced in Fin08, and (apparently) to punish us for their mistake, they have limited us to exactly 4 Staff Lists in Fin09, no more, no less. That's usually about all I need: All Staves, Top Staff, Bottom Staff, and Tempo Staves. I'm not sure if one can change the
Re: [Finale] Some comments re Fin09
On 25.07.2008 Robert Patterson wrote: This seems really plausible until you start thinking about layers, grace notes, v1/v2, and even tuplets of 0-length. All of these mean that an unlimited number of notes can coincide at the same beat location. Can you tell us the consequences? Personally it seems to me that the new system is inferior to the old in terms of flexibility and adjustability, am I correct? I am not sure whether you prefer the old or the new system, and whether you, as a pro user will use 2k9 rather than stay with 2k7 or 2k8. For me it seems that any improvement on the buggy engraver slurs is worth going for the new version, as I am spending far too much time on finding and correcting buggy slurs. Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
At 09:51 AM 7/25/2008, Robert Patterson wrote: Here is the next really good thing. Expressions can now be placed in categories, and every expression in that category can have the same settings. I'd like to clarify these points in Robert's excellent post. Expressions now *must* belong to a category, not can. There are 7 built-in categories, representing likely groups of expressions (dynamics, tempo marks, tempo alterations, expressive text, technique text, rehearsal marks) plus Miscellaneous. You can also create your own categories based on these default ones. The idea is that expressions in each category are likely to have similar formatting (font style and size, positioning, staff list), and having them in a category gives you a way to change the formatting for all expressions in the category at once. (Miscellaneous is designed as a catch-all for expressions which *don't* naturally fall into a group with others and hence don't share settings.) Also, it's important to emphasize that expressions in a given category *can* have the same settings, not must. Individual expressions in a category can override any of the category's settings -- but then if you change the category's settings, expressions which have overridden them will not be affected. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Some comments re Fin09
On 25.07.2008 Williams, Jim wrote: WHAT DO I MISS??? That's easy...ABILITY TO RUN PLUGINS ON LINKED PARTS!! Ah, that brings up a question: Does collision remover work on parts now? Johannes -- http://www.musikmanufaktur.com http://www.camerata-berolinensis.de ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
