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]
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
