On 13 Jul 2002, at 12:17, Johannes Gebauer wrote: > On 13.07.2002 2:28 Uhr, Richard Walker wrote > > > 1. Linkage between scores and extracted parts. If I update one, the other > > should be updated automatically. Ideally, extracted parts could be viewed in > > some sort of pop-up window from the main score--triple click an instrument > > name and its part comes up for editing. > > > To be honest, I don't think we can expect anything like this in the next > version of Finale. However, I think the ideal way to implement this would be > to have parts _inside_ the score file. I can see a lot of problems with > this. Perhaps, now that plugins can operate on several open documents there > is scope for a clever plugin.
Another approach would be to have the part files store only the "delta" from the score for the same part. That is, all the part file would have in it would be the things that were *different* from the corresponding part in the score. Anything that was not changed would simply be inherited from the score. It would be nice if it were possible to propagate a change in a part back up to the score, too. That, then, would give you the option of changing the score or not, and it would mean that the work to get a part read would be completely minimal. Of course, there would be problems if, for instance, your part file had a "delta" listing for an item in the score that eventually got deleted from the score. In that case, the part file would have to be smart enough to cross-check "delta" data against the score and remove obsolete data. I can see problems with that. Of course, with that change, it would also be a good idea to allow part creation in the same fashion as Finale now does it, with files that are fully independent of the score itself. That way, everyone could be kept happy. On the other hand, I can see this kind of thing as fraught with difficulties, and my experience leads me to believe that it would be better if parts were stored in the score. In that case, the parts would be a substructure in the score file describing the delta from the score version of the same part. I think this would be much more stable, since the problem with deletions would vanish as the "delta" would simply be a child record in the database and when its parent object was deleted, the child record would be deleted along with it. If again the option to save the parts out to separate files was also retained, you'd have the best of both worlds. But this would be a major piece of work for Coda. However, I think it would be quite an important and useful enhancement. [] > > 8. Editable mirrors. Maybe I want the same basic phrase, except for one or > > two notes that need to be taken down an octave. Or maybe chord symbols need > > to be added. Or maybe I only want to mirror the second layer. The mirror > > should keep the link and also remember what is different, so that if the > > original is changed, the mirror is updated intelligently. > > Now that's something I think is a good idea. Don't the so-called "tilting mirrors" already do this? Now, I've never been able to understand them, but theoretically the feature is there, no? -- David W. Fenton | http://www.bway.net/~dfenton David Fenton Associates | http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
