On 25 Mar 2004 at 7:01, David H. Bailey wrote: > However, when Sib3 saves files in Sib2 format, you lose all of the new > features that Sib3 has initiated, such as colors that correspond to > some school music instrument made out of colored tubes that kids whack > when they see that colored note. So you can create a beautiful score > in Sib3 with everything you want, save it in Sib2 format to send to a > buddy for additional editing, and when they send that Sib2 file back > to you with the changes, you have to go right back and re-edit all > that colored stuff you originally worked so hard to get just right.
No one with half a brain or less should think it would work any differently than that. > It's another marketing ploy to show how "superior" they are to Finale > that works just as we all know it would work in Finale. Personally, I > am glad we can't do that because it would cause code-bloat for no > really good purpose (how would those engraver slurs look if they were > converted to Finale 2000 file format?) Converters are generally not part of the base executable, but external libraries that are called on demand, so, while adding this feature might very well add to the number and total size of the files in your Finale program folder, it shouldn't in any way cause any significant bloat to base executable. In any event, who cares if the executable is 10MBs? In the days of 40MB hard drives, yes, that mattered (most of us had only 640K of RAM, then, too), but it doesn't matter today when most machines have well over 10GBs of hard disk space as well as a minimum of 128MBs of RAM (and most newer machines have more). > I would rather see the development team work harder to get things > right in the current version, such as PDF printing for the poor MacOSX > users who had to wait so long for a workable Finale. Once, created, converters to older versions would never have to be tweaked, as they would only need to know about the features supported in the older version (i.e., extensions to the file format in newser shouldn't need to be written into the converters for older file formats). So, the main programming effort would basically be a one- time operation (though the converters would have to be tested with each new version, but a certain amount of that work is already being done with the one-way converters that read older files and convert them to the current file format). If they'd done this for Finale 2000, we'd now have a set of converters that would work for all the recent versions of Finale. So, I don't see it as such as tradeoff. Yes, it would take a big effort for the first backward converter, most of it architectural, but after that, it oughtn't be a huge amount of work compared to the original effort. And you get nothing until the first effort is invested. While I agree that there are crucial bugs that need to be addressed quickly, it's not really fair to cast this as a choice between Mac PDF printing and backward compatibility in file formats. The effort it will take to fix the PDF problem is probably a couple of orders of magnitude smaller than the effort required to create converters for older versions of Finale. > And then to work further on the MIDI tool, to allow us to actually > EDIT musically meaningful things in the Human Playback dialog, so we > can determine if trills start on the upper note, how fast they are, > whether they end with a bit of sustained original note. But, again, *I* don't see any real need for human playback. Yes, it's a nice feature, but now that it's there, I'd think that it's better to let it coast for a couple of versions while they address problems going back to older features that are of much greater value. > Far more important to get things working right in the current version. But it's *always* a trade-off between short-term and long-term and between features and bugs. > When they finally have gotten their data to a point where anything we > want to do notationally (well, I can wait forever for the ability to > create spiral scores a la Crumb) is possible. Then the data format > will be mature and they can begin making version compatibility > possible. By that time, Finale will cease to exist precisely because users don't like to be forced to upgrade every year, and so people will stop buying the product. > The Sib3 saving as Sib2 is most definitely NOT a reason to switch! Very true. But when we're talking about first-time notation program users, it's a *major* difference, since it tells you you're not locked unto an upgrade treamill. > Join the Sibelius group at yahoogroup and read all the "it used to > work this way on the Acorn version, why doesn't it work in version 2?" > and "it didn't work in version 2, why doesn't it work yet in version > 3?" messages and realize that Sibelius is way behind Finale in terms > of program maturity. That may be, but it's a helluva lot easier for novices to get decent output out of it. And that's going to eventually kill Finale if Code doesn't address some major lacks in the program. Lack of any backward file conversion is a major issue, and really ought to be addressed. Of course, I often wonder if it's not something that could be reverse- engineered from ETF files. You could take a file that has just about everything in it in an early version of Finale, and open it and save it in successive versions, and then compare the ETFs. Of course, you'd also have to be sure to test the newly added features, such as engraver slurs and that kind of thing. But even a crude conversion might be sufficient for some purposes (though obviously not for collaboration). And I'm not even sure it would require Coda's involvement to do it, since ETF files are just text files. Obviously, on the subtleties, their involvement would definitely help, but it should be something an outside developer could get started with. Of course, perhaps that's how Dolet is already doing what they've so far accomplished. -- David W. Fenton http://www.bway.net/~dfenton No Comment Blog ttp://www.bway.net/~dfenton/NoComment _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
