Dorico should be better at avoiding collisions by default

There are definitely some weaknesses here. I particularly notice this with rehearsal marks and system text.

And in a perfect world where anything is possible without unacceptable development cost or performance penalties, it would be really cool if, when we manually move an element in ENGRAVE mode, the casting off process would recognize this adjustment and rerun its automatic layout to account for the possibility that I have just relieved a collision.

Again, this is most evident to me with rehearsal marks. They can often force adjacent systems to be placed way too far apart in order to make room for a rehearsal mark that is in a bad place to start with. But when you manually fix the placement of the rehearsal mark, the staves remain spaced too far apart. So then, you have to go down the rabbit hole of manually adjusting the staff spacing and before you know it, you are fiddling with many objects manually.

This sounds dire, but honestly, I have found a combination of settings that look good and donā€™t really require much manual editing. It wasnā€™t obvious, and I had a lot of frustration before I eventually got it settled out.

One thing I have noticed is that, if it is convenient for rehearsal marks to come at the beginning of a system, there are fewer spacing problems. That isnā€™t always possible or desirable, of course.

4 Likes

Another way that would involve less constant calculation could simply be a properties checkbox to ignore that element when calculating vertical spacing. Any element - Text, System Text, Tempo, Rehearsal Mark, Chord Symbol, etc. - could be selected and then once checked, Dorico would no longer factor it into any vertical spacing calculation. Not exactly what you are asking for, but a lot of times I think this could lead to much better results and certainly less manual fiddling of staff positioning.

8 Likes

How are you presenting this music to your musicians? On paper? On Tablets?

For what itā€™s worth, my music frame margins (top and bottom) are 8mm. But youā€™re missing the point. Many of the elements on a system (including the notes themselves) are not considered when casting off. If you look at the link to another thread I posted a few messages back youā€™ll see an admission that the notes and their offset from the staff are not considered (nor system/staff attached text) This will invariably cause systems to collide. Unless your systems are relatively uniform no amount of fiddling with margins and spacing is going to work when the software isnā€™t even considering many of the elements on the page.

My request was a simple one (though perhaps not simple at a coding level). Having the layout process take into consideration the actual height of the system and all itā€™s associated elements so collisions donā€™t happen by default.

ā€“Neil

Itā€™s up to the musician. I give them PDFs formatted for printing. Some print, others use tablets.

ā€“Neil

I canā€™t upload my score. Itā€™s a work in progress and Iā€™m not comfortable doing that. But hereā€™s a contrived file that shows the problems I run into. This was created (I believe) with all defaults. Things to note.

Bar 11 - system attached text runs off the top of the page
Bar 20 - turn on engraving mode and youā€™ll see that the slur and articulations are outside the music frame
Bar 23 - Tempo marking is outside the music frame

Flow 2 bar 1 - Text runs into header
contrived example.dorico (780.0 KB)

Your request is indeed simple. But so is a request for World Peace.

None of the issues you raise is unknown to the Dev Team. They have all been discussed here at length over the years. In particular the management of space above the top stave in the presence of blocks of text, and Doricoā€™s handling of stacked system objects.

That said, with Dorico, I find I spend far less time fretting over layout than I used to in Sibelius.

It begs the question of how this can actually be fixed. Clearly, it isnā€™t right for anything to protrude beyond the frame boundaries. But if it were fixed now, that could be disastrous for so many earlier projects.

I guess they could define a property for a music frame that allowed a music frame to work in classic mode or in corrected mode.

In my opinion, no object should ever be allowed to protrude outside the music frame. I basically see it as the edge of the copper plate. Stuff in the margin, or running into headers, is ugly and always wrong, and Dorico shouldnā€™t allow it.

2 Likes

These are recognisable problems to me, as well. I often have text which runs past a frame boundary but if Dorico were to solve this automatically, it might involve moving a bar to the next system, which might again lead to an ugly layout. In such cases, I would rather tweak the text myself, either by changing its shape or by nudging it in Engrave Mode.

I often run into a problem with lyrics at the end of a system, especially ones with long syllables and with hyphens, which then get buried underneath the lyric text. Since Dorico doesnā€™t adjust for this automatically, I have to wait until the final layout before tackling the often daunting task of checking every system an increasing gaps at system ends. If then the layout needs to change after all, I not only have to go through the process again but I also have to remove my previous tweaks.

Rehearsal marks often throw a wrench in the works for me, too, as described above. Aside from the staff spacing problems already discussed, I often have to tweak RM to avoid colliding with the key signature accidentals at the beginning of a system. This really shouldnā€™t be necessary!

2 Likes

No begetting required. The Dev Team will come up with an elegant solution.

I agree with the complainers about the margins. This has been brought up and discussed repeatedly in the last 5 years. Please see Danielā€™s responses in those two threads. I do not have my hopes up that they will ever regard this as important enough to fix.

Not that I donā€™t recognize your issue, but I have troubles with your approach.

Early in this thread you said that you prefer readable layout above beautiful layout. Later you mention that you are trying to put as many systems as possible on one page. For me, these two statements are contradictory, and it seems to me that in the end you DO want to have a beautiful layout.

I only have one theater project a year, but there I clearly go for the legibility route: huge page and frame margins, big vertical spacing and extensive horizontal spacing.
I rarely have issues with what you mentioned. Sure there are edge-cases, mostly itā€™s Tempo Text going beyond the end of the page.

I would really recommend you doing the same. If your top and bottom margins are big enough, there will literally never be a situation where notes are off the page. With luxurious spacing options, people might have to do more page turns, but you are able to quickly deliver new versions for the next day.

2 Likes

I also think the way to avoid ripple effects of format changes is to put added or (duplicated and) modified flows at the end of the project.

  1. Presumably the producers do not pay to reprint an entire score and part book for each player; so one can as easily print new parts (for the added or changed material) from the appended flows, or in the case of those reading from tablets, rearrange the pages within a PDF Editing Program.
  2. Later, when one has time, one can clean up the score for publication or whatnot.

That sums up my feeling about computer programs and music, with the addition of: the program should allow me to be truly free to do the nuanced, human stuff.

The historical trajectory as been for beams to get flatter and flatter, and this has lead to the latest Henle style, which certainly makes life easier for engravers using current software.

In earlier times avoiding conflicts between the melodic shape and the beam slant was a much higher priority than avoiding wedges (even through wedges were more of a printing issue than they are today.)

There is no reason that a computer program couldnā€™t duplicate the older and to me much more human and musical beaming style. But that would involve a much deeper analysis of the subject than has been done up until now.

1 Like

I wholeheartedly agree that we should strive to have Dorico do as many of the mundane editing things as possible, and this includes considering what could be considered egregious errors. So hear me when I say: I do not mean to denigrate or invalidate any of the posts above. That said, I feel compelled to repeat something I have said at other times; namely: that we have to be realistic and expect to do some work to our scores manually. Music making and engraving are human art forms. Only a human can determine the best page turns (barring long periods of rest), or make subtle tweaks here and there to improve spacing in a way that looks more natural to the eye than even very well-refined algorithms. Ultimately, I think it unreasonable (and as un-human as 1980ā€™s midi) to want, or even hope for Dorico to do everything a fine engraver would do. Notes and lyrics certainly shouldnā€™t run off the page into the abyss, but I also canā€™t expect a computer program to be able to competently handle literally every possible musical permutation that humans can conceive to satisfaction for everyone. Forgive me for waxing poetic about this.

6 Likes

Iā€™ve moved this lengthy discussion from the already very unwieldy thread in which it was originally posted. Iā€™m sure Neil didnā€™t intend it to generate quite so much discussion, but since it has, Iā€™ve moved it into its own thread.

Although weā€™ve certainly been around this topic many times here on the forum, a few quick points from me:

We have no deep-rooted philosophical objection to adding options to move systems vertically to avoid things protruding out the top or bottom of the music frame, and we will very probably add such an option at some point in the future.

We also recognise that there are problems that occur when you move items on the outer staves of systems (like rehearsal marks, tempos, chord symbols, etc.), and that Dorico could make a better fist of vertical spacing if it took the adjusted positions into account. This one does run a bit more counter to our core approach, namely that in order to achieve a stable result that doesnā€™t unexpectedly ping staves all over the place, we always use the calculated positions of items to determine ideal spacing, since the calculated position doesnā€™t (typically) change. But at the same time itā€™s clear that if we could optionally allow this, it would be helpful.

Finally, in terms of the general problem with avoiding collisions between items on separate systems on the same page, that oneā€™s really difficult to solve, but I agree that in principle itā€™s definitely something that Dorico should do. None of us in the team thinks itā€™s acceptable for systems to collide by default. The problem is that coming up with a solution for this problem is a lot harder than it might seem, and the result might still be ugly: essentially, if you end up with a system colliding with another system, then the last system in the frame needs to be moved to the next one (and thus causing all remaining systems to be cast off again), but if there were only two systems in the frame, then chances are the single remaining system is going to look pretty poor, either squished up at the top of the page or unnaturally spread out. Both of those results would be better, of course, since the music would be legible in both cases, but neither would perhaps be ideal.

In any case, weā€™ll certainly return to these areas in future. There is always more to be done in the area of producing a pleasing layout as quickly and efficiently as possible, and we donā€™t consider any of this to be in its final, ideal state.

16 Likes

I would note that, at least in the case of rehearsal marks, the solution is to allow the algorithms certain flexibility to adjust the rehearsal marks laterally (horizontally). The last thing I want is for the rehearsal mark to move up, up, up away from its corresponding measure, and in the process forcing unwanted gaps between systems. In traditional engraving, one often sees rehearsal marks moved left or right up to a half measure before or after the corresponding barline. The intent remains clear, especially if a double bar is used at the rehearsal point.

I realize that describing it and programming it are two entirely different things. Iā€™m sure there are all sorts of consequences to consider.

This is what I ended up doing once I realized that editing a flow could cause my engraving to get clobbered.

1 Like