On 7 Jul 2005 at 23:18, Johannes Gebauer wrote: > Andrew Stiller schrieb: > > > > On Jul 6, 2005, at 1:29 PM, Aaron Sherber wrote: > > > >> In dynamic parts, each part is nothing more or less than a special > >> view of the score. The reason that note changes to score are > >> reflected immediately in the parts and vice versa is because the > >> notes are only stored in one place. On the other hand, the file > >> keeps track of different positioning information for things like > >> expressions -- one position in the score and a different one in the > >> part -- so that you can make small tweaks as needed. > >> > >> Aaron. > > > > I can dig it, but: > > > > Tacet movements and other omitted or added measures for one part > > (e.g., optional cadenza not written out in score)? > > > > Cue notes--not in score, and different in different parts? > > > > Divisi on 2 staves vs. 1? > > > > Above all, as I've just remarked elsewhere: different Page Setup > > settings? > > And much more basic: as Robert remarked it is absolutely essential to > have separate spacing for each part. The way that Finale's spacing > works I fear that this might indeed make the "one file, different > views" approach incredibly complicated, as the data will have to be > separated into "global" and "part" data, and in fact every element has > to be effectively both, with individual decision on what is global and > what isn't.
Well, it all depends on where the spacing data is stored. If it's stored as part of the entry record, then it's a problem. If it's stored as a separate record attached to the entry record, then it's not a problem at all. What I mean by that is, if you have a note, that's an entry record (a row in a table in the Finale database). If the spacing data is stored in fields that are part of the entry record, then it won't work. If, instead, spacing data is stored in a different table, with a link to the ID of the entry record it applies to, there's no problem. You'd simply have one table for the score spacing data, and a second table for the part spacing data. Or a single table that indicates which view the spacing applies to. >From a database point of view, it's not even an insurmountable task to move data out of one table into a separate table that is linked to it. I've done that kind of thing millions of times. It could also be done by keeping the old data structure and storing the spacing data in the main entry table, then having an additional table that includes records attached to the entry data that would override the score spacing when the other views were used. This would mean that the existing score/scroll views could remain unchanged, and the only new code required would be to handle the new views and incorporating the additional spacing data that's stored in the other data structure. So, in other words, I've argued myself into seeing this as technically not even close to being insurmountable. That doesn't mean it's easy, but it's not significantly different from storing independent spacing data about entry-attached items (like note expressions). There would just be more of it, and hardly any of it would be inherited from the score file. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
