On Jul 6, 2005, at 11:39 PM, David W. Fenton wrote:
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.
Actually, the 2005 version of repeats is very close to being excellent.
The only place I have to enter information that should be gleaned
automatically is when I create a 2nd ending. The "2" is put in
automatically (editable, though) as is the ending box, while it STILL
assumes I want a backwards repeat at the end of the box which I have to
uncheck. Still, that's only ONE extra mouse click, instead of MANY, for
pretty much perfect repeats.
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?
I dunno.
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.
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.
I have a USB MIDI interface (4 ports) plugged into one of two available
USB ports, also a Logitech wireless mouse, and of course my computer
keyboard, both plugged into my screen's USB port, as designed. I
occasionally plug a SanDisk memory card reader, or a Cue Cat barcode
reader (don't ask!) into the other port, but the problem is there even
when neither one is plugged in.
I do have a wireless router plugged into my Ethernet port for an
Appletalk 10baseT local network supporting my cable modem, my LaserJet
4 printer, and my wife's laptop. I also have an external Firewire drive
plugged into one of the two Firewire ports almost constantly. But those
shouldn't affect things adversely, should they?
I think you shouldn't have the problem you're having with the current
beaming algorithm.
Heh, heh! I agree!
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.
Well, I have no way to verify that. I'm not much of a gearhead,
admittedly.
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! :)
Hey, it ALL sounds reasonable enough to me!
Christopher
_______________________________________________
Finale mailing list
Finale@shsu.edu
http://lists.shsu.edu/mailman/listinfo/finale
