On 7 Jul 2005 at 1:00, Noel Stoutenburg wrote: > Christopher Smith wrote: > > > 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! > > Well, I do not not expect Finale to remember the MIDI note I was > holding when I hit the number key. If Finale is "well behaved" that > is, if it follows the rules and conventions established for the > Operating System, what seems to be Finale "remembering" entries in the > numeric keypad, is actually an artifact of Finale getting the next > keystroke in the Keyboard buffer of the O.S. I can't say whether it > is possible, or rather how difficult it would be, for Finale to > implement a shadow MIDI key buffer that could be somehow linked to the > OS keyboard buffer, so that when Finale gets the sixteenth item from > the keyboard buffer, it also gets the sixteenth item from the MIDI > buffer.
Well, it can't be done by event count, since you can have a different number of events. If you get 16 from the MIDI interface and 15 from the keyboard, you want the extra from the MIDI interface ignored, because it didn't have a corresponding rhythmic value. Likewise, if you have 16 from the keyboard and 15 from the MIDI device, you want the 16th used, since it indicates the rhythmic value for a rest. So, it's not about matching up sequential items between two buffers. It's about the "timecode" on each event -- they have to be received in the order they were sent in order for Finale to make sense of them. That is, the keyboard data has to come between the NOTE ON/NOTE OFF from the MIDI keyboard in order for Finale to know the rhythmic value of the note. It has to be real-time data, and that's why I suggested that the problems Chris were having were caused by some kind of timing problems in the USB bus, and the easiest suggestion to test this is to take one of the devices off the USB bus, so that there's no longer contention on the bus, or artifacts of any possible inaccuracies in the timing data used by the USB bus. > > If Finale has a more complex beaming algorithm than it presently > > does, no doubt this problem will get worse. > > I doubt that, as the beaming algorithm is strictly computation and > followed by redraw, and the problem you describe, of numeric keypad > entries not matching the correct pitches is a hardware / OS problem. And the redraw probably takes thousands more CPU cycles than the calculation. -- 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
