On 6 Jun 2005 at 8:44, Darcy James Argue wrote: > You need to use a separate set of dynamics for vocal staves, defined > to go above the staff instead of below. > > There is a Choral Dynamics library (already set up for placement above > the staff) in the Maestro Font folder inside your Libraries folder. > Load that library, and use those dynamics for the vocal staff
As wonderful as the automatic positioning of expressions is, it seems clear to me from these instructions that Finale still remains in the dark ages of software design because, once again, a feature is implemented that requires proliferation of object definitions. I have said it a million times: you should define a dynamic marking once, and then be able to sub-class it so that you can have different versions of it that have properties that over-ride those of the basic dynamic mark definition. Either that, or you should be able to position the dynamics above or below the staff. This seems especially so if, as I understand from the description, the same UI for horizontal baseline positioning that is found with lyrics is being re-used for expressions. That's a good thing, but it's *bad* that it works differently (i.e., you can't drag the baseleline above the staff). I have always felt that the need to proliferate expression and articulation definitions is a massive flaw in Finale, even with the ability since 2K4 to at least be able to distinguish the different versions of the expressions (though I've not heard anything about how one distinguishes articulations -- still nothing?). Finale data is stored in a database, and individual expressions can be dragged around onscreen, so there's already somewhere in the data storage hierarchy that stores individual positioning information. It seems to me that it shouldn't be all that difficult (and I say this as someone who makes his living as a database application programmer) to add a higher level of the hierarchy, that serves as a master definition. It doesn't even require the creation of a new data table, just the addition of a new field in the existing definition that points to a parent object (in database terms, a self-join). As for UI, it could be as simple as: - duplicate an existing expression/articulation definition - in the dialog defining that new item, there's a check box that says "maintain link to source definition." This could be turned off by default, so that anyone who doesn't like this idea could continue to use expression/articulation definitions just as they always have. Better still would be if the UI also indicated what the parent object was, and had some easy way to inspect its properties. Perhaps it would be better if any properties that were altered from the parent were indicated in a different color in the properties dialog. It would also be good if parent definitions were distinguished in the expression/articulation dialogs in some way so you would realize those were not deletable without causing cascading consequences. Comments welcome, and if there's enough interest and we can work it into something clear that many people find useful, I'll forward it to MM as a feature suggestion. -- 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
