On 6 Jul 2005 at 21:17, Christopher Smith wrote: > > On Jul 6, 2005, at 12:39 PM, David W. Fenton wrote: > > > On 6 Jul 2005 at 9:57, Christopher Smith wrote: > > > >> On Jul 5, 2005, at 7:57 PM, David W. Fenton wrote: > > > >>>> 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. > > Well, you WOULD see it as relevant if you had Finale slow to a crawl > when Auto-Word Extensions is on in your 300 measure choral work with > orchestra and several vocal soloists. Having word extensions update > ONLY when I ask them to from a plugin is a distinct advantage in > speed.
Well, that's actually a poorly-chosen example. Beaming is calculated as you edit the notes. That is, when you enter an 8th note, then enter a second one, the calculation of beam angle occurs right then, before the 2nd 8th note is displayed. If you add a 3rd 8th note as part of the beam, it then recalculates the beam angle, and if you add a 4th, it recalculates again. It's using a very small amount of data, the data that describes the notes within the current beamed group, and based on a certain algorithm, displays that single group. After that, there is no further re-calculation. But when you edit the notes in the beamed grouping, such as dragging a note to the right or left, or by changing one of the pitches or adding additional pitches, the beaming is recalculated. The CPU cycles are used *as needed*, and only when there is an edit to the data that forms the inputs to the algorithm to calculate beam angle. That's the place where Robert's code should be. And given the contemplation of dynamic parts, where a transposed part might end up with different wedges than the concert pitch version in the score, it seems obvious to me that the adjustments that Robert's plug-in makes belong in Finale's basic beaming algorithm. And it wouldn't add any overhead or slowdown to the data entry process at all. > >>> 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. > > Sorry, I missed what the problem was originally (I need to read > better). > > This doesn't seem to happen on my Mac version, though I DO have to hit > redraw once I am back in the score for my measure number edits to show > up properly. > > Sounds like a bug. Well, it can mostly be ameliorated by setting the defaults for measure regions, but it's nonetheless a bug. -- 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
