On 5 Jun 2004 at 0:17, Christopher BJ Smith wrote:
> Well, I have a couple of macros to accomplish it. Mostly I want tokeep 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 think you may have misread my intent. I wasn't afraid that linked parts would take away my present work method, I was just explaining why linked parts aren't important to me. However, now that I have checked out a bit what advantages might be involved, I think I am coming around.
What I AM afraid of is new features taking time away from working out the bugs in the features that are already there, or creating a program that is so bloated that it won't run at a usable speed except on the newest hardware.
> You know, this is what I was referring to when I mentionedexperienced 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
(good stuff snipped)
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.
I had gathered as much from some other explanations that came my way since I confessed ignorance. This looks actually quite interesting. Did you see my reply enumerating what I thought such a architecture should contain? Do you see anything missing?
Christopher _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
