On 3 Mar 2005 at 19:37, Mark D Lew wrote: > On Mar 3, 2005, at 6:40 PM, David W. Fenton wrote: > > > Do you currently have to define default vertical spacing for systems > > on a per-system basis? No, of course not -- there are default > > settings already. The default setting for the system I describe > > would be that the default vertical spacing for a measure would be > > equal to the system margins. If you reduced the vertical spacing for > > all the measures in a system, the system margins could then > > automatically contract. If you increased the vertical spacing for a > > selected block of measures, it would cause the system margins to > > expand to accommodate it. > > I don't understand this paragraph. The default vertical spacing for > any system is the global positions set up in scroll view (ie, what I > think of as the "unoptimized' spacing). I have no idea what you mean > by "system margins". Maybe I do things differently, or maybe this is > another semantic thing.
We're talking past each other. I'm talking about system spacing and you're talking about spacing between staves within a system. Both are pre-defined when you go into page view, so, there's no reason that measure margins would not also be pre-defined by the same mechanism as system margins. > > Say you had only one measure in a system that needed expanded > > vertical space. In the current situation, you adjust the vertical > > spacing for the system to accommodate the measure that is the > > extreme case. If that measure gets moved to another system, you have > > to start over, changing two systems. If, on the other hand, you set > > the vertical spacing for that one measure, if it got moved to > > another system, the target system would then expand accordingly, and > > the original system would contract back to the defaults (or to the > > next smallest setting in the measures in that system). > > OK, that makes sense. I'm in the habit of doing all my layout > adjustments only after layout is set, so the change wouldn't really > benefit me much, but I can see how it would be a great help to people > who make large changes to a piece after layout has already been set. You never change your mind? I usually lay out a piece onscreen, then print it and then make adjustments to the layout because of problems I couldn't perceive onscreen. > I doubt that Finale would want to have that AND the ability to adjust > by system. If so, and the change is made, then whenever I have > page-specific adjustments I'd have to do them indirectly by simply > selecting all the measures in that system and adjusting accordingly. > But that would be all right. At that point, I won't be changing the > layout anyway, so it all comes out the same. I don't see why you couldn't have both. > > You have a very strange definition of the word. Optimization means > > REMOVING BLANK SYSTEMS. Read the optimization dialog box -- it says > > nothing about vertical spacing of staves within systems. > > I'm using Fin Mac 2k2. My optimization dialog box says this: > > << Optimizing can remove empty staves from Page View AND/OR make > staves in specified systems independently adjustable. >> > > In other words, Finale thinks that both functions are part of > optimization. In fact, the "AND/OR" is not quite accurate. While it > is possible to optimize without removing empty staves, it is not > possible to optimize without making staves independently adjustable. > > I've quoted verbatim from the dialog box. If your version of Finale > says something different, that could explain our disagreement about > the meaning of the term. The Windows dialog is the same, but there are no settings in the dialog that have anything whatsoever to do with vertical staff spacing -- all the settings have to do with showing/hiding systems. The way I see it is that this is the tail wagging the dog, because without having grafted the vertical spacing feature onto optimization, there'd be no logical reason to have the ability to optimize without hiding systems. That is, if as I suggest, all systems in page view had two handles (as happens currently after optimization), then there would no longer be any relationship between vertical staff spacing and the process of optimization, and the ability to uncheck "Remove Empty Staves" would then serve no function whatsoever, since right now, all it does is turn on the ability to space staves vertically (if it's unchecked). I understand your point of view that changing inter-system spacing is part of "optimizing" your layout for the pages, but I think it's a mistake in the design of Finale, as it means that, in cases where you *don't* want staves hidden if empty, you have to turn on optimization before you can adjust vertical spacing. I think that's a ridiculous requirement. > >> I believe this would satisfy both us, yes? > > > > Pretty much. But I still like the idea of vertical spacing > > travelling with the measure, not being permanently anchored to an > > absolute system position. > > I'd be OK with that. Aside from the matter of what to call it, it > looks like you and I are in agreement on this. There very well might be better conceptual ways to implement this than what I've described, but I think my point is clear: the way Finale works requires more work than it need have, as it requires you to think of systems as empty slots that the music pours into, and that the slots have their own characteristics (vertical spacing, hidden staves) that are independent of what music is displayed in them. Now, yes, we can all think of unusual situations where this can actually be turned to advantage, but it is still antithetical to the most obvious way of thinking about how it should happen (in my opinion). Spacing of systems and hidden blank staves should be determined by the content of the music, not by which system slot the measures end up in. > > I just don't see why it is conceptually any different than what we > > have now with the way system margins live inside page margins. > > I still don't understand what you mean by "system margins". In Page View, click on the handle in the upper left of the system and from the context menu choose EDIT MARGINS. That's what I'm talking about -- the margins of the system. As I said above, you were talking about spacing between staves within a system, I was talking about spacing between whole systems, and the solution I described only solved that problem. I see no reason (other than increasing complexity of UI and onscreen representation of the margins) that my ideas couldn't be applied within between staves within a system as well. Of course, I also think that the role of scroll view in setting vertical spacing between systems is a ridiculous holdover from the old days. If you've ever done a score such as piano chamber music where some of the systems are at a smaller percentage than others (strings at 75% vs. piano at 100% in a piano quartet, for instance), you see what kinds of problems the interdependence between scroll view staff spacing and page view vertical spacing causes. An example: Here's a perfectly OK page (in terms of vertical spacing of staves; this isn't finished, as I haven't done any final layout, as I'm still editing the expressions/articulations/slurs): http://dfenton.com/Midi/StaffSpacing-FullPage.gif Compare that to the third system as shown in scroll view: http://dfenton.com/Midi/StaffSpacing-ScrollView.gif It's pretty bad, in terms of the problems of collisions between staves. And those examples aren't even the worst, by far. Look at this: http://dfenton.com/Midi/StaffSpacing-ScrollView2.gif and the page view: http://dfenton.com/Midi/StaffSpacing-FullPage2.gif Now, obviously, I'd have to change the inter-staff spacing in the third system, but the point is that it is *very* hard to work in scroll view with this percentage reduction of the string parts because scroll view doesn't reduce the size of the notes (as in page view), but still keeps the reduced vertical spacing necessary to get the page view to look correct. Now, you may quibble with the percentage reduction I'm using here, but the point is that the vertical staff spacing in scroll view should be COMPLETELY INDEPENDENT of the vertical spacing in page view, so as to avoid problems like this. [] > > Why would I *ever* suggest taking away the fine control that Finale > > has always offered? > > I know you well enough to know that you wouldn't want that. But you > did say: > > >> I think it's > >> crazy that the optimization information is stored with the absolute > >> system rather than as a global setting that automatically updates > >> the optimization when conditions change to warrant it. > > By either definition of optimization, that suggests change from > system-by-system control to a single global control, which in turn > implies loss of control at the system level. I was just clarifying > that some of us prefer not to lose that control -- so that, for > instance, you could still make a blank staff appear when you want it, > without having to resort to the real-whole-rest kludge. Global settings do not imply a complete absence of overrides to the global settings. To me, in many cases, Finale seems to be designed more to handle the exceptions, rather than to make "normal" music easy! -- 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
