I have a suggestion for your backwards compatibility -- keep all the previous versions on your computer and simply work in the version that works for your client.
I find your suggestion that in order for finale to have backward compatibility I would have to remember what new features have been added since the version I wish to save to, and then to avoid using the features that make Finale much easier to use, to be pretty silly.
You want the end user to have to emasculate the program and revert to working using techniques we all used to complain about, simply so the program can advertise backward compatibility? Somehow the logic escapes me -- in that case it isn't the program which is backwards compatible, but rather the end-user which is backwards compatible.
I don't consider the use of smart shapes to insert 8va lines, slurs, arpeggio lines, hairpins, etc., to be "making the score look pretty." I find those to be inherent to the very music itself, and to be items that many people ended up adding by hand in the earlier versions because they were either impossible or extremely difficult.
Are you really suggesting that in order to have backward compatibility we have to revert to all that?
Wow!
Craig Parmerlee wrote:
As I suggested earlier, when using an object based storage approach (which apparently Finale doesn't) the normal practice would be to store multiple versions of the objects so that back level releases would be able to see something they recognize.
As a user, I'd know that I shouldn't invest a lot of effort during the collaboration phase making the score look pretty. I'd do that work at the end of the project in a final typesetting pass.
It is no different with Word, Excel or any other end-user application. If you are collaborating electronically, it is up to the user to avoid the use of features that are above the "least common dominator" of the software in use by the partners. There really isn't anything new about that, as far as I can see.
Regards, Craig
At 09:21 PM 6/6/2003 -0400, David H. Bailey wrote:
Craig, which items would you leave out of a Finale2003 file when you were saving to 2002 format? To a 3.2 format?
How would the program be able to deliver any sort of file that would be usable in 3.2 (pre-smart-shape days) when it was filled with smart-shapes? How useful would that be? Lyric extensions?
How useful would a file be if you spent 100 hours entering an orchestral score in 2003 only to find that you have to redo almost that entire 100 hours of work because none of your slurs were saved and no hairpins and no arpeggio lines, and on and on and on?
These are not insignificant items which have been added on with each new release, and to omit any of them would render backwards compatibility less than useless.
You can petition them for backwards compatibility if you like -- I'm still hoping they can finally get midi file import and hyperscribe working properly!
Maybe you could come up with a list of what you would be willing to see omitted from a 2003 file to achieve backwards compatibility and have the file open in finale 3.2, and then we could have a better idea of what you are suggesting.
Craig Parmerlee wrote:
At 07:11 PM 6/6/2003 -0400, David W. Fenton wrote:
On 5 Jun 2003 at 23:19, Craig Parmerlee wrote:
> Coda is possibly the only vendor of a > major software product that does not provide backwards compatibility.
It depends on the product category. It is very common with database programs to *not* have backward compatibility, or only limited backward compatibility.
I don't mean to be pedantic, but all the DB systems I am familiar with provide the means for inter-release compatibility forward AND backward.
This includes DB2, Oracle, Access, Paradox, and rBase, to name a few.
For backward compatibility, with any of these systems, you have the ability to build your data base in a prior format that is recognized by earlier versions. That may prevent you from using the latest features with your new DB. It is a trade-off of flexibility versus new function. But the key point is that the user gets to make that decision.
Also, end-user database products like Paradox and Access allow SaveAs to a multitude of formats, so it is easy to use those products on collaborative projects.
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale .
-- David H. Bailey [EMAIL PROTECTED]
.
-- David H. Bailey [EMAIL PROTECTED]
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
