On 06.06.2003 7:08 Uhr, Craig Parmerlee wrote

> 
> If this is a difficult feature to incorporate into Finale, the only
> explanation is that the programmers did not plan for this requirement.  My
> suggestion is that they get help.  Find somebody who understands how to
> plan for inter-release compatibility.  When you have the right technical
> strategy, this is not a difficult problem.

I really am no programmer, but I am pretty sure you cannot compare Finale to
other applications that do offer backwards compatibility.
I can see two different sorts of applications that offer backwards
compatibility:
1) Apps using a standard file format, where new features do not require any
change in the file format. A good example is Bias Peak, an Audio editor. It
saves standard file formats like AIFF, SDII and WAV, plus some of it's own
eg for playlists. Feature additions only add new ways of _manipulating_ the
data, not the way the manipulated data is being saved. Backwards
Compatibility is naturally no problem.
2) Apps that use their own format and add certain features that require the
file format to be changed. These can be devided into another two categories:
a) Apps which have a file format which earlier versions can still read by
simply ignoring new additions to the file format.
b) Apps that allow saving in an earlier version's file format by simply
omitting new features.

The only way I can see possible in Finale is the last (2b). There are some
fundamental problems that are specific to Finale, however. If you compare it
to a word processor, there is relatively little you can add once you have a
standard way of saving the text itself. Most formatting options are the same
for even the earliest versions of the file format. Those parts which change
simply change a few control codes, or add some, that can quite easily be
ignored when saved for earlier versions.

With Finale the situation is much more complicated. Firstly when new
features are added, they may have such a fundamental influence on how
certain things are saved withing the file format. Take staff styles. They so
completely change the look of a score in certain situations, that backwards
compatibility with any faithful representation of the score is nearly or
completely impossible. Take slurs. They started off as measure items, than
note attached slurs were added, and finally Engraver slurs. If you want to
save an Engraver slur in a format preceding note attached slurs, what will
you get?
Take Text Blocks. Take tabulature. Take midmeasure clefs.

How are you going to include all the things that are simply impossible in
earlier versions but cannot be ignored.

Me, I can easily live without backwards compatibility and would not get a
new version that adds this as the only new feature. It is more important to
me that _I_ can read all existing Finale versions.
As a compensation Coda/MakeMusic offers Finale NotePad. In addition there
are several ways of producing PDFs from Finale files, some of them free.
MusicXML is another way for Windows users (when will we finally get this
plugin for Mac?) to achieve some kind of backwards compatibility.

I personally have accepted that full backwards compatibility, while perhaps
not impossible, would still be a major investment for Coda, holding up new
features considerably. I would not want Coda to take this route.
> 
> For the less computer-intense folks, here's an analogy.  Doing a 4-part
> voicing in realistic Bach fugue style is terribly difficult if you don't
> know what you're doing.  For an accomplished arranger, it is just about
> automatic.

I don't see the analogy. A computer could write a perfect fugue. A computer
could not program backwards compatibility all by itself.

Johannes
-- 
http://www.musikmanufaktur.com
http://www.camerata-berolinensis.de

_______________________________________________
Finale mailing list
[EMAIL PROTECTED]
http://mail.shsu.edu/mailman/listinfo/finale

Reply via email to