On 5 Jun 2004 at 0:17, Christopher BJ Smith wrote: > At 5:35 PM -0700 6/04/04, Eric Dannewitz wrote: > >Christopher BJ Smith wrote: > > > >>Once again, my little copying routine that I noted is so easy, that > >>I can hardly imagine justifying the kind of rewriting it would take > >>to accomplish linking ONLY notes in Finale. And doesn't anyone edit > >>anything else? > >> > >But if you find yourself doing this a LOT, wouldn't you think that > >there ought to be an easier way to do it? And yes, people do edit > >other things, but if this linking was done right it would be slick. > > Well, I have a couple of macros to accomplish it. Mostly I want to > keep control. I re-extract when I see the need, and use the routine I > outlined when it would create less work.
But why do you simply *assume* that linked parts would take away control and prevent you from using your present routine? I don't see anyone who wants linked parts advocating the removal of the present part extraction methods. > >No, I'm not saying for Finale to start TELLING you what to do. I hate > >that as well, but it would make a lot of sense to be able to have a > >score with related parts that are linked at a user defined degree. > >Think of it like a relational database. You might think an Excel > >datasheet works for everything, and when someone proposes to > >"relationalize" your data, you might think "what's the point", but in > >the bigger picture it makes a whole lot more sense, and I think the > >next step in Finale would be to do this. > > You know, this is what I was referring to when I mentioned > experienced programmers seeming to see things that I don't. I don't > understand the term "relational database." Maybe if I did, I would > "get" what all you guys want out of Finale. The key distinction between data stored in a spreadsheet and data stored in a relational database is that the latter separates data storage from data presentation, whereas in a spreadsheet, the place where you store the data is the same place used for printing -- there is no separation between data layout and print layout in a spreadsheet (though that's not entirely true -- certain kinds of features do allow multiple presentations of the same data from one worksheet). In a relational database, the data is stored in objects that are designed to represent the characteristics of the data itself, with no concern for printout or presentation. In a relational database, a report can be used to draw data from multiple related data tables and present it in any number of different ways, each specific to the purpose of the individual report, hiding certain things, revealing certain others. For example: http://www.bway.net/~dfassoc/Park/Reports.html There are a couple dozen reports, presenting data mostly from a handful of data tables. In a spreadsheet, each of those reports would require its own spreadsheet page (or, perhaps, in the case of closely related reports, editing of a single spreadsheet page to produce two slighly different printouts), but in a relational database, the report layout is defined entirely separately from the data, allowing an infinite number of presentations, without requiring re-arrangement of the underlying data. A score printout and a part printout ought to be defined at the same level, as something cosmetic that is independent of the underlying music represented in it. Then you could have as many different presentations as you wanted, and changes to the music would flow through into all the various printed versions. -- 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
