On 6 Jul 2005 at 9:57, Christopher Smith wrote: > On Jul 5, 2005, at 7:57 PM, David W. Fenton wrote: > > > > I have always felt that the easiest way for Finale to get "linked > > parts" (I hesitate to use that expression, since it seems tied into > > the in my opinion erroneous idea that the parts should be in > > separate files, linked back to a score file) was to fix special part > > extraction so that the layout changes for each part were stored as > > deltas from the score layout. > > That was the argument that won me over. Well, as a computer programmer, it would never occur to me to implement it in any other way. Finale screams out for an object- oriented approach to both implementation under the hood and user interface. The inheritance/encapsulation/subclassing that comes with object-oriented programming works exactly in this fashion by taking a basic object, subclassing it and adding interfaces/methods to the new object that is based on the other object.
That's exactly what a different view is. It's also very much in line with my background as a database application programmer, where you do report layouts to present data that's stored in a format completely independent from the presentation format (i.e., it's not at all like a spreadsheet, where the data is stored in the same format you print, and alterations to the spreadsheet affect its layout for printing, with no independence between the two). So, the ideas seem self-evident to me. > >> It'll be > >> interesting to see how the new mid-measure repeats business works > >> and whether or not it will adjust the measure numbers > >> appropriately. > > > > Isn't it just implemented as a plug-in? > > Is there a problem with that? Plugins seem to be a good way to go, as > they don't take up CPU cycles when you are using the program > "normally". This is what I like about the TG Tools lyric plugins, for > example, over Finale's auto-word extensions. Well, I would assume that code that implements the MassEdit tool's functionality doesn't take up CPU cycles when I'm in Speedy, so I don't see this defense of plugins as relevant. To me, the basic functionality of the repeat tool should be changed to use common sense. Such as, if you place a backward repeat, Finale should find the previous forward repeat and say "do you want to repeat to the forward repeat at m. N?" and have a button called "SHOW ME" that shows you the context, and then allows you to say YES / NO / EDIT MANUALLY. > > If you add a new region, when you create it, it appears to inherit > > all the settings of the previous region you were working on, but, > > instead, it just doesn't update the display. When you close the > > dialog, you find that it's actually inherited the default settings > > for measure number formatting. Second, there are problems with the > > measure-number display that I haven't quite traced down. It takes > > two or three trips to the region editing dialog before the numbers > > start actually displaying what you've told them to > > Command-D (control D on the PC) to redraw usually takes care of it for > me. Ctrl-D in a *dialog* box? The dialog box shows the WRONG FONT. And the display has already been updated, since when I return to the document, the measure-number font is different than it was before I opened the dialog (it's now set to the default). Why in the world would a modal dialog box that makes changes to objects displayed onscreen not automatically update the display as soon as the dialog is closed? That sounds like sloppy programming to me. -- 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
