On 5 Jun 2004 at 1:55, Christopher BJ Smith wrote: > Now comes the hard part: How far away is Finale's structure from a > relational database to be able to accomplish this in a reasonable > number of programmer hours?
Finale's data is already stored in a database. Whether it's truly relational or not isn't really the point. The point is that page layout information is stored separately from the music data. I'm not saying it would be easy to do this -- indeed, it would probably be quite difficult -- but there is nothing inherent to the way Finale stores its data (so far as I understand it) that would make it impossible. It should only require an extension to the file format to store the additional layout information and changes to the program to allow the application of that additional layout information to the appropriate contexts. You described the feature set just about perfectly, actually. Programming difficulties aside, wouldn't you *want* those features if Coda implemented them? Wouldn't they greatly improve your productivity? If find that extracting parts is one of the most unpleasant parts of Finale -- I put it off and put it off, especially because after proofing the first run of them, I always have to go back and alter the score, and in many cases the changes are numerous enough that I feel that I need to re-extract the parts (instead of making the changes in two locations). While linked parts wouldn't completely eliminate the work it would take to prepare parts the first time, it would vastly reduce the amount of work it takes to implement revisions to the parts once they are laid out the first time. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
