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.
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!
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.
If Finale has a more complex beaming algorithm than it presently does,
no doubt this problem will get worse.
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.
Christopher
_______________________________________________
Finale mailing list
[email protected]
http://lists.shsu.edu/mailman/listinfo/finale
