Vertical staff spacing

Hello,

After having worked with Dorico on a few projects after making the switch from Sibelius, there is one particular issue that I seem to have on a regular basis. The vertical spacing of staves often doesn’t make sense given manual adjustments I have made. As an example, in a part where a rehearsal mark on one system would collide with a dynamic from another system, Dorico adds extra space between the systems. This is fine, until I move the dynamic in engrave mode so that there is no longer a collision so that the systems can be equally spaced. However, Dorico seems to not realize that I have moved the dynamic manually and continues to add unnecessary extra space between the systems, which then looks strange because there is now no visual reason for that extra space. The result is that I then have to take all systems below that point and nudge them up manually so that the result is more visually pleasing. This happens as well if I add text with Shift-X - the text is by default placed high above the staff, and even if I move it down in engrave mode manually, Dorico thinks the text is where it originally was before I moved it, and I end up with strange looking extra space above random staves where I added the text (unless I take the time to make manual staff spacing adjustments, which I often do).

Then if I make edits to the music, Dorico resets the staff spacing and I have to go and make these manual adjustments to each staff again. I had a piece lately with many revisions where I don’t know how many hours I had to spend moving staves up and down after edits. I have another revision to make soon and I am dreading it because I know there is going to be another set of painful hours of fine tuning vertical alignment of systems to get a reasonable result, so that when I give it to the performers it doesn’t look stupid.

Is there something I am doing wrong? Is there a better way of handling this?

Thanks

Many objects have an “Avoids Collisions” property. If you’re going to move an object manually, it can be really helpful to turn off its “Avoid Collisions” property, from the Properties panel. That way Dorico won’t create extra space for that item.

I often find it necessary to turn off “Avoid Collisions” for rehearsal marks, especially for parts.

It’d be handy to be able to turn on and off the Avoid Collisions property on an individual basis. Or is it possible? I just selected a dynamic but was unable to find a setting in the Properties Panel, either in Write or Engrave mode.

Yes.

You can set which parts have Avoid collisions active. Go to Layout Mode, select the part you want to effect (or not) - from the Layout list down the right hand side, and click apply.

A propos collision: How is it possible that the attached page layout is the default given by Dorico?

Oh. This one again. See „Resolve the collision..” strange behavior - Dorico - Steinberg Forums - it’s essentially the same question.

Only text items have a property for whether or not they participate in collision avoidance. What Dave (TopDots) is referring to is the switch on the Vertical Spacing page of Layout Options that allows you to disable Dorico’s automatic collision avoidance for adjacent staves.

The issue that Michael is describing in the initial post in this thread is a deliberate behaviour: in order to make Dorico’s spacing stable, moving an item in Engrave mode generally (with a few exceptions) does not alter the calculation of the distance between staves and systems. Moving a rehearsal mark out of the way, for example, will not cause Dorico to close up the gap between systems. This is, as I say, to ensure that its results are stable and that you won’t find the program sneaking around behind you adjusting things after you have made decisions about where things should go.

Daniel,

Thanks for clarifying. Now it’s clear the post was a more in depth that I initially thought. The trouble with speed reading I suppose…

This, to me, is one of the very best advantages of Dorico over Finale. When I used Finale, moving any item on a “finished” piece was highly risky — it was often the case that by simply moving one small item, the entire score would get messed up. Finished layouts in Dorico feel much more “solid” because of this behavior, making it much easier to edit scores.

I don;t see how it is beneficial to make poor vertical spacing stable. Particularly with rehearsal marks (but it comes up in other cases as well) we often end up with vertical spacing that is not acceptable, even for a quick draft. And the work-around is not very nice, usually requiring the staff spacing to be overridden for multiple systems.

That is frustrating because, other than these few cases of really bad behavior, the default spacing chosen by Dorico is usually very nice. It can be maddening to be so close, and then find it necessary to basically lay everything out manually because of the cases described in this thread.

I think we can all understand if the answer is that with the current release, a decision was taken to leave these very problematic cases because a more elegant solution might be needed. I think everybody would be patient for a more elegant solution in the future. But I get the feeling that Steinberg doesn’t even consider this to be a problem. If so, I think that’s the wrong answer.

Craig, I politely disagree with your assumption. At the very least, the team intend to revisit vertical spacing.

(„Resolve the collision..” strange behavior - Dorico - Steinberg Forums)

Thanks for that. I appreciate that there can be a certain recursiveness to this situation, and that can be the enemy of fast response time while working interactively. It seems to me that the current design philosophy of Dorico is to have WYSIWYG in all cases – in other words, no separation of draft mode and “real layout” mode. And to the extent that is possible, it makes for the most intuitive user experience. I don’t deny that.

But this may be a case where some things are really too computationally expensive to be done in real time. It seems to me that Engrave mode should allow for more computationally expensive layout decisions. Fundamentally (on a non-technical level), the problem seems simple. The casting off should do its best job of laying out the vertical spacing after accounting automatically for any collisions. And when the human imposes a placement decision (moving rehearsal marks or whatever,) then the casting off process should make a new set of decisions. This type of thing already happens (very successfully) when one inserts system breaks. I don’t see why the manual placement of an object should be any different from the act of inserting a system break.

No doubt this is must easier said than done, but it does not strike me as an insurmountable, “circular”, or “catch 22” problem.

As the system currently exists, I find myself including fewer rehearsal marks than I normally would, simply because I don’t want to have to deal with this vertical spacing problem any more than necessary. I hope the software evolves such that I can insert rehearsal marks all the places that make musical sense.

As a thought, what about being able to manually trigger recalculation of casting-off after moving an object? For instance, if you move a dynamic out of the way in engrave mode so that it no longer collides with a rehearsal mark, being able to right click on the moved dynamic and choose “recalculate collisions for this object” or something along those lines?

Or maybe it can be automatic but some kind of locking system put in place when it isn’t wanted?

I think you haven’t quite got the point of what is being said about this.

Actually, there is a notation package that works exactly this way already - Lilypond. It is not interactive at all, and “rendering” a 100 page score to create a PDF typically takes minutes, not seconds.

LIlypond effectively takes every barline as a possible system break point, and finds the combination over the whole document which balances the amount of stretching or squashing of each separate system against the best use of vertical space, including trying to match up repeats with system breaks, multirests with page turns, and starting of separate flows (in Dorico terminology) on new pages, etc.

The results can be wonderful, especially if you give it a few hints as to what matters most.

But there is only one “little” problem: it’s not unknown to fix a typo in the score which adds an accidental somewhere and therefore changes the optimum width of a single bar - and 20 pages of the score get completely repaginated. Of course the reformatted version looks as good as the original - unless you had tweaked the shape of a slur somewhere, and now it is split across two systems instead of being on one, or similar things.

The difference in the “best” formatting can be out of all proportion to the tiny change you made. For instance in a collection of short pieces, a piece that was formatted tightly onto a single page might now be spread over most of two pages, to line up the start of other pieces in the complete document with page breaks. That sort of thing can seriously mess up any manual formatting tweaks - lyrics alignment, for example.

In other words, for every tiny change you make, you have to re-proof-read EVERYTHING, “just in case”.

Life isn’t long enough for that level of perfection!

I feel like this has been discussed here on the forum, although I can’t remember exactly. I agree totally, this would be great.

I think I get the point of it. Dorico does a great job of automatically laying out parts – much better than any other product I have used, except for a couple of significant exceptions. Unfortunately those exceptions are pretty severe if a person wants to use features like rehearsal marks and other things that don’t cooperate very well. We are hoping these will be addressed before too long. I am very confident this can be done without making any major compromises to the architecture of Dorico, because most of the visual elements already play nice. We’re just asking for the troublesome ones to get addressed in due course.

In other words, it probably isn’t necessary to process recursively in response to manual adjustments if the root cause of the manual adjustments is improved.