Horizontal alignment of accidental for adjacent note
1. Open attached score (produced in 1.3).
Expected (?) result:
Actual result:
Discussion: It's sort-of a continuation on this issue: #1464: Faulty vertical alignment of accidentals at chords
I'm not really knowledgable in this area. Pages 87-91 of 'Behind Bars' touches on this subject, but I wonder if it and MuseScore (also LilyPond 2.18.2, Sibelius 7.5, Harmony Assistant 9.6.3i and Finale 2014) perhaps misses something. Maybe my published example is incorrect?
Using MuseScore 2.0 Nightly Build (601b10b) - Mac 10.7.5.
Comments
You don't have any note without an accidental, hence no root in the current key so why do you need or want all those double-flats? It's an A dim 7 ( or a C dim 7, or an Eb dim 7 etc.) so you can pick any note as "root". Even if you're in Bb minor, for instance (it sort of sounds as if it's trying to resolve to this or, maybe, E minor), you can get away with just two naturals. If you are trying to faithfully copy an original then, OK, I can see the point but bear in mind that the engraver or setter didn't necessarily get it optimal in the first place.
In reply to You don't have any note by underquark
You can now see a bit more ;).
You have to let go of the notion that there is a "right" or "wrong" about such things. Different engravers - human and computer alike - will follow different rukes and heuristics, with just a few general guidelines that everyone agrees in. It's a fascinating topic, but not one that will have any one resolution.
I'd personally rate the "expected" results you show to be pretty clearly sub-optimal. You can't get around the need for at least four columns here, but in choosing the order they did, they've missed out on any opportunity to have the columns overlap as MuseScore does in tucking the Dbb under the Gb. They deviate from both of most well established general layouts - zig zag and diagonal - for no apparent gain. I suppose whatever algorithm they followed might produce better results for *some* case, but this is pretty clearly not one of them. MuseScore manages a more compact arrangement with needing to deviate from either the zig zag or octave "rules".
In reply to You have to let go of the by Marc Sabatella
At the time, I thought handling of the accidentals was possibly based on a right-to-left order of the noteheads (E♭, then the rest).
In reply to At the time, I thought by chen lung
Most algorithms do indeed work right to left; the question is just which accidental to start with. As I mentioned, there are two main basic algorithms - one that zig zags back and forth from top to bottom, and one that works top down along the diagonal, moving back in when possible and starting a new diagonal. Most engravers follow one of these two basic conventions, but this example does neither. Also, if one is to align octaves, the octave columns normally go first (ie, furthest to the right). There might be special cases where a clever engraver sees an opportunity to get a more compact arrangement or perhaps some other advantage by deviating from these norms, but here, the engraver followed neither the zig zag nor the diagonal rule, *and* he broke the rule about putting octave columns first - and to show for it, he got a *less* compact arrangement. So, as I said, pretty clearly sub-optimal. I'm sure he had *some* strategy in mind, and I'm sure it was a fine strategy for other cases, but not this one.
Anyhow, the lesson is this: even experienced engravers follow different rules and produce different results. And a strategy that produces optimal results in one case might produce sub-optimal results in another. So consistently following any single strategy means some chords will look better than others; that's just a fact of life. And if you tried adopting a strategy that said, "try every possible combination and pick the one that is most optimal", you'd end up with a hodge-podge of different types of arrangements (some basically zig zag, some basically diagonal, etc) that would look terrible on the page and would just confuse the eye. So you really are better off sticking to one basic strategy, maybe tweaking it here and there where you find a small change that makes for a more compact arrangement.
But as the article I reference elsewhere earlier (http://blog.steinberg.net/2014/03/development-diary-part-six/) clearly shows, everyone ends up with different answers. It's amazing how much variety there is in this. So expecting any particular program to exactly the match any particular published example is just plain not realistic. It's not going to happen, since different publishers will produce different results for the same example.
Bottom line: unless you see something that is clearly way off (not following the zig zag rule at all, accidentals overlapping, accidentals sticking out way too far to the left all by themselves, etc), there is pretty much no point worrying about the differences you see in accidental stacking from one engraver (human or otherwise) to another.
In reply to Most algorithms do indeed by Marc Sabatella
Sorry, I should have clarified: I meant accidentals for notes on the right side of the stem would be processed at once (hence why the E♭ appears furthest to the right of the others), then the same for notes on the left.
I think I accept your explanation. Thanks Marc.