On 6 Jul 2005 at 23:10, Christopher Smith wrote: > On Jul 6, 2005, at 9:47 PM, David W. Fenton wrote: > > > 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. > > Sorry again. I thought we talking about mid-measure repeats being > implemented as a plugin (as quoted at the top), not Patterson beams.
Er, um, ack, yes, that's what we were talking about. A plugin for repeats is certainly more appropriate, in my opinion, than a plugin for beaming, but I still think the basic functionality of repeats is obtuse and ridiculous. In my database application programming I have a rule: never require a user to put in data that my program can retrieve or calculate without user input. Repeat targets are something that could easily be calculated (though, obviously, with nested repeats, there'd need to be confirmation and the ability to override Finale's guess) without user intervention in the UI, without need to resort to a plugin. > Yet my concern about slowdown holds even more with a new beam > algorithm. Even now, I often find myself "getting ahead" of Speedy > Entry. I discovered, disconcertingly, that Finale "remembers" the > numeric keypad keys I hit for rhythmic values in sequential order (as > you would expect) but DOES NOT remember what MIDI note I was holding > down at the time I hit the number key! I have never had any such trouble in WinFin, and I put in data *very* fast. Is it perhaps an OS X problem, a remaining artifact of the yet- to-be-fully-optimized-for-OS-X Finale? > For instance, if I have a quick scale passage to enter in eighth > notes, I can quickly hit > note-4-note-4-note-4-note-4-note-4-note-4-note-4-note-4 to fill the > measure, but when I look up at the screen, Finale is laboriously > catching up with me, and furthermore, it has often entered an EIGHTH > REST in the middle of the bar and continued mismatching pitches with > eighth note values to the end, occasionally putting the interval of a > second on a stem, too, as if it "saw" two notes being held down > instead of the one. This occurs more frequently when I pass over a > barline, or if the screen scrolls just as I get to end of a measure. I've never encountered that. First off, I'd do CAPS LOCK 4, then play the notes, since I sometimes get my hands out of order, but I certainly never have that much lag time. Is your MIDI interface USB? If so, you may have something else contending for the bandwidth of the USB interface, and that could be the reason you're having the problem. But on WinFin with my MIDI interface on my sound card, I see no such lag. > If Finale has a more complex beaming algorithm than it presently does, > no doubt this problem will get worse. I think you shouldn't have the problem you're having with the current beaming algorithm. > Admittedly, I am on a rather middle-to-slow system about two years old > (!) a 733 mHz G4, but I would have expected Finale's buffers to stay > synchronised in any case. Your system is faster than mine, a 500MHz 1st-generation P4 with 768MBs of RAM. Sounds like an interface problem to me. Or a severe problem with Finale's OS X implementation. Even so, I doubt the algorithm would actually take any longer. Computers are *very* fast. The lag in your system is, I'm absolutely certain, not in the calculations, but in the transmission and display of the data you're inputting. Even adding 10 settings to beaming would not likely increase the beam angle calculation time by a few milliseconds. If it were more than that, Patterson beams would take hours to run, when, in fact, it actually only takes a few seconds to a few minutes on my machine in order to recalculate every beam in every frame in an entire piece. That's hundreds of thousands of calculations in a very short period of time. No, I'd wager that the slowdown you're experiencing would not be noticeably increased by adding a more complex beam angle algorithm. It's kind of like the issue with printing -- the slowdown in printing is your *printer*, so increasing the formatting time of a document by, say 500 milliseconds per page is probably not going to increase the amount of time between clicking PRINT and having your completed document by more than about 500 milliseconds (which is added onto the time before the first page is handed off to the printer). It's important in computer programming to not worry overly much about percentage increases in the time it takes to perform an operation unless that operation is being performed literally 1000s of times per second. Since you can't enter even 100 notes in a second (at least, notes that each independently need to be factored into a beam angle algorithm), it's unlikely that doubling the amount of time Finale takes to calculate beam angle for each edit would be noticeable. Then again, I'm speculating about a program whose internal structure I haven't a clue about running on an OS I've barely touched, so if you think I'm full of hooey, I can see why you'd think that! :) -- 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
