On 3 Mar 2005 at 7:06, Christopher Smith wrote: > On Mar 2, 2005, at 10:35 PM, David W. Fenton wrote: > > > On 2 Mar 2005 at 20:18, Christopher Smith wrote: > > > >>> disappearing measures, > >> > >> I've never seen that. What is that? I have occasionally seen > >> measures APPEAR to vanish, but that is usually because I had a > >> multi-measure rest where I later entered notes, and forgot to turn > >> off the rest. > > > > Well, that does strike me as the kind of problem that no intelligent > > application should allow to happen. Notes in measures should > > automatically break multi-measure rests, without the user being > > required to do anything. > > I'm not sure I want ANOTHER automatic sweep through a subroutine > slowing down the performance of the program, like Auto Update Layout, > Auto Update Hyphens and Smart Word Extensions and the like. . . .
All of those can be turned off, right? So why do you assume that automatic breaking of multi-measure rests would not also have the option to turn it off? Or, as I suggested with automatic optimization in a response to Johannes, perhaps a setting to have it occur with Ctrl-U. > . . . Especially > given how often this problem (if it is one) would show up. I've only > seen it myself a couple of times, and I am a heavy user who revises > works constantly. Multi-measure rests only appear in page view. Since you can see or edit the measures the multi-measure rests represent, the change of layout would happen when you switch from scroll view to page view. So, there wouldn't be any need for a process constantly running to check for multi-measure rests -- the code to do that would need to fire only at the point where you switch from scroll to page view. And it would be nice if it would fire with a Ctrl-U, as well, I think, especially for cases where you remove existing data and want rests combined. On the other hand, that raises some problems, and might be better left as a manual process because you probably wouldn't want it automatically combining two multi-measure rests (e.g., if you had an 8-mm rest followed by a measure of music followed by another 8-mm rest -- you probably wouldn't want the two rests combined with the new empty measure into a 17-mm rest). You could have a behavior where if there's a multi-measure rest on *one* end of the measure you empty, that the empty measure would then automatically combine with the adjacent rest, but then there'd be different behaviors for different contexts, so that's probably not a good idea (at least not as a default behavior). So, probably the creation of *new* multi-measure rests after music has been removed should probably not happen automatically while editing in page view, since there's too many cases where it will simply guess wrong because of all the ambiguities involved. Overall, I'd think the multi-measure rest re-calculation should have a setting to turn it off, but then should be controllable where it fires. I think it should fire with the switch from scroll to page view and on Ctrl-U. > > I also think that staff optimization should not be something that > > you have to remove and then re-apply. If you insert new measures, or > > insert data in previously empty measures (or you clear/hide > > previously populated measures), if you've got optimization turned > > on, it should automatically cause the system to re-optimize. I > > Re-optimize to what parameters? There's a whole window of options > there for that process. I don't want to be asked every time, and I > don't want Finale choosing the parameters for me. I would rather do it > myself. Well, as in all these suggestions, I'm not suggesting that the behavior be changed by completely eliminating the old way. Others have already outlined how that could work. Automatic optimization would happen according to the settings in the Staff System Optimization dialog box, just as they do now. It's just that you wouldn't have to invoke the dialog to make it happen, nor un- optimize and re-optimize when you change the layout. And it would be nice to be able to lock optimizations to absolute systems, as Johannes suggested, which is rather similar to the way you can lock systems already (it's not too much of a different concept). I still think these are two examples where Finale doesn't behave with common sense, and it's precisely these kinds of things that cause people to prefer programs like Sibelius, which behave according to one version of "common sense" but then prohibit you from making it behave any other way. If Finale retained user control, but also incorporated "common sense" by default, who could complain? Honestly, I'd *never* need to know anything about the optimization dialog if Finale did it automatically, or much of anything about breaking/combining multi-measure rests (though I certainly do believe these should correspond to musical phrase divisions and large sectional boundaries, which isn't something that can happen automatically). Why should I need to know those things at all? In an ideal notation program, the novice user gets standard notation that behaves exactly the way the user expects, and the advanced user gets all the control she needs over the parameters that control how the layout behaves. Finale has always been long on the latter and short on the former, for a number of reasons (many of which are legacies of the old days of computing, where limited resources dictated modal approaches to editing and manual updating of layouts). -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
