Yes, definitely Finale fits into that second category "apps that use their own format". If the app is alive and growing there WILL be format changes. Maybe not on every single release, but change is inevitable.
Software designers have realized this for at least 30 years. There have been a variety of strategies used to successfully deal with the problem.
OK, here is some free consulting. This is the sort of thing that corporations pay $1000/day or better for.
In the modern software era, development environments and the programmers that use them organize their data into objects. In the case of Finale, examples of objects are notes, articulations, pages, staves, and so on. Basically any discrete item can be seen as an object.
Each object may have some properties. Properties of a page might include its dimensions and margins. Properties of a staff could include the style (percussion, 5-line, etc) and its transposition.
To ensure compatibility forward AND BACKWARDS, you need 3 things:
1) an orderly, predictable nomenclature for your objects
2) well conceived properties that are not easily outdated
3) a hierarchical storage system that reflects which objects own other objects (as in articulations belong to notes which belong to measures which belong to staves which belong to groups which belong to pages which belong to the MUS file itself)
Once you have that -- and that is the most natural way to store files anyway -- the problem is practically solved. Take a hypothetical product Widget2002 that has the sort of structure described above. Widget2002 was programmed such that it can ignore any objects and properties it doesn't recognize. If Widget2003 introduces a new object or property, no problem. Widget2002 simply ignores it and continues.
Occasionally the concepts behind an object change so radically that you it would foul up the prior version (e.g. the meaning of particular properties changes). An example might be the evolution of the SmartShapes in Finale. In cases like these, the programmer would typically create a new object type to replace the old object. However, if the new object was really essential (as in SmartShapes), then the programmer should do the extra work to include BOTH objects -- new and old -- in the file. That way Widget2002 will see an object it recognizes (the 2002 version of the object). And when Widget2003 users open the same file, they see the other version of the object (the 2003 version). Both users are happy.
I'm not talking some fantasy here. This is how modern software is developed every day. Doing it right doesn't necessarily require a lot of extra programming.
Cheers, Craig
At 12:33 PM 6/6/2003 +0200, Johannes Gebauer wrote:
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
_______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
