Faulty vertical alignment of accidentals at chords

In this case MuseScore is following the correct alignment rules but most scorewriters (including LilyPond).give the accidentals a larger margin which forces the different arrangement.

Probably MuseScore should give larger margins for accidentals since it looks like some of these accidentals are overlapping.

I reworked the accidental layout in rev. 1722. Two new style parameters are now available to adjust the distance between accidentals-notes and accidentals-accidentals. I found some infos for accidental layout from J.Gedan at http://www.pian-e-forte.de/texte/index.htm and changed the layout algorithm to match the given examples (well, mostly).

The (now old) implementation was based on http://mpa.org/music_notation/standard_practice.pdf.
J.Gedan talks about "exceptions" from his base rule but does not explain them. The last chord example seems to be such an exeption but i cannot see a rule/algorithm which i can implement.

Well, I guess that was solved for normal chords, but if the chord is divided in several voices, the accidental arrangement can be pretty messy.

Also observe how the accidental layout varies depending on which voice (1 or 2) has each part of the chord.

Look how bad looks the 2nd example.

The result is the same on both 1.2. and 2.0.

Maybe that other example was a bit extreme, but compare this simpler one:
Everything in 1 voice (OK) vs. 2 voices (different layout!).

R.2d3b0b9 - Windows xp

I noticed this problem recently.

I think the original (an extract from a published book by International Music Publications and engraved by Barnes Music Engraving) was produced in a software called Amadeus (according to an interview ).

I'm not sure either LilyPond or MuseScore get it right.

Using MuseScore 2.0 Nightly Build (68f7856) and LilyPond 2.16.1-1 - Mac 10.7.5.

Hi Magnus

I think it's actually more incorrect "horizontal" alignment (rather than "vertical")?

I thought "faulty" was perhaps not the right word :).

Related issue - sharps and naturals seem to line up on a 45 degree angle when there are lots of them. The attached file is a G sharp major chord followed by a G natural chord. There is no way to shift the accidentals so that they take up less room.

Using nightly build c56fa93 under Windows 7,

I'm reading about the subject in Elaine Gould's book and trying to summarise.

For the excerpt I posted: Magnus's 'Variant 2' and 'LilyPond' are the same. The 'Original' almost is too, except the ♭ of the E is closest to the notes, with the note head being right of a chord with adjacent notes - does the book account for something like this?

I entered Guifre's example and adjusted the accidentals to what I think maybe in accordance with Elaine Gould's recommendations in her 'Behind Bars' book.

Open in 1.2.

Here is LilyPond, which might be better in some aspects, but I don't think it's completely right either.

Werner or David :D?

Okay. Here are PNG's.

Check voice 1 + voice 2 vs. chord in voice 1 in the attached score, they show the accidentals differently (in a different order), in 1.3 as well as 725882f.
Or is this a different problem? Or none at all?

A workaround for the time being is to exchange voices 1 & 2 (using edit, voices) and then change the stem directions (using general style, voices).

For future reference, see http://blog.steinberg.net/2014/03/development-diary-part-six/
And especially, http://blog.steinberg.net/accidental-stacking-comparison/ (MuseScore 1.3 is probably product D)

Since I've been working on this for the past week, I'd like to share my thought for those interested in discussion.

For the record, in the comparison lasconic links to, "Product D is a commercial scoring product no longer under development or indeed widely used, but still used by some top publishers; Product E is a popular open source scoring program with a graphical user interface". So I guess D might be "Score", but I assume we're E. Accidental placement looks like ours, but I am confused by some issues with notehead position that are *not* issues I expect. I am assuming these were the result of flawed MusicXML import.

Anyhow, for those who haven't been following the recent discussion on another issue here in the tracker, see http://musescore.org/en/node/3325#comment-97139. As part of my overall chord layout fixes, I have implemented a number of improvements to accidental positioning. The open question to me is still the basic "stacking order", which is what this thread is mostly about.

Previously (I guess since Werner response #3 above), MuseScore's rule could be stated as follows:

Place accidental for top note, starting to left of leftmost note. Place accidental for bottom note, offset to the left if necessary. Then return to the second highest note, and place accidentals further and further to the left. I'll summarize this as "top, bottom, diagonal".

There are probably as many different rules out there as there are notation programs and authors of books on engraving. The one I learned originally is basically the one from the MPA guidelines, which I'll state as follows:

Place accidental for top note starting as close the notehead as possible. Place accidentals for successive lower notes by offsetting to the left as necessary. The first time it becomes possible to place an accidental next to a note again, do so, and then continue with successive notes, offsetting to the left until it becomes possible to place an accidental next to a note again, etc I'll summarize this as "parallel diagonals".

Elaine Gould's "Behind Bars" has become the go-to reference for a lot of people in the brief time since it was published. Her rule can be stated as follows:

Place accidental for top note starting as close the notehead as possible. Next place the accidental for the bottom note, offsetting to the left as necessary. Then alternate between the next highest and next lowest, note, continually moving to the left as necessary. I'll summarize this as "zig zag".

The problem is that each of these rules produces great results in some cases and non-so-great results in others. Plus, there are a few special modifications to these rules some publishers will adhere to, such as trying to align accidentals for notes an octave apart, making sure the diagonal formed by accidentals matches that formed by that formed by the noteheads themselves in the case of seconds, etc.

The way I have re-structured the code, the actual stacking order algorithm is completely divorced from the details of detecting conflicts and figuring out how far an accidental needs to be offset to the left. I could even refactor it further such that any of the above algorithms could be implemented in less than a dozen lines of code. This would allow us to make the stacking order a style option, or have some heuristic for choosing which order to use based on the chord density or whatever - even for the code to try multiple options and then choose the most optimal.

But at some point, I think we need to stand back and accept we're not trying to be LilyPond. We don't need optimal results in all cases, and in any event we can't afford the time it would take calculate this. We need a solution that produces good results in most cases and provides predictable starting point for potential manual adjustment.

I would claim any of these stacking order algorithms could give us this much, but if there is any sort of consensus that some other method is better than the "zig zag" one described by Gould and also Spreadbury, I'm happy to implement that.

Marc's improvements have been merged in 6d1da20ec129c

Comments are welcome. Here are some tests cases https://github.com/musescore/MuseScore/commit/6d1da20ec129cb2f792f84046…

Between the above and also the PR merged for #25055: Poor accidental layout on large / complex chords, I think we can consider this fixed.

Most of this particular thread was related to non-complex layout of accidentals in the presence of multiple voices.

In other words, the algorithm was already fine for these simpler chords but if the higher notes in the chord came from a lower numbered voice it caused the algorithm to misbehave.

I am all in favor of the new improvements, but I wonder if the other problem related to multiple voices has been addressed at the same time.

It should be fine. Can you provide an example?

Sure, see #8, #9, and #26 in this thread.

Rick, try the examples you quoted for yourself. They work fine in the improved layout code.

To be clear, the original problem report for this particular issue had nothing to do with multiple voices. It was, from the beginning, about single voice chords and the basic stacking order. Some of this is quite subjective - there are multiple legitimate stacking orders. In fact there was nothing particularly *wrong* about the actual example that started the issue, and some of the well-respect guielines would lead to exactly that result (MPA, for example). So it was really mostly an editorial difference of opinion. And in any case, the results from the original examples were actually changed years ago to be what was expected.

There was, of course, *also* a bug involving multiple voices where indeed the results were objectively *wrong*, but that wasn't mentioned until response #8. This is really totally separate and should have received its own issue probably.

The bug with multiple voices was actually fixed a week or so ago as part of #3325: Seconds between voices overlap. The underlying causes were the same, so fixing the issue with seconds in multiple voices actually fixed the accidental issue as well with no further effort required.

But the main issue being discussed in this thread - the stacking of accidentals in ordinary single-voice chords - was not fixed until the commit mentioned in the response #31. Again, it's subjective, so it's tough to say the new code is more "correct", but it definitely results in more compact arrangements on average, and it also respects the alignment of octaves, which in fact is really the only reason to have a preference in the example given in the original report.

Bottom line, as far as I know, all problems mentioned anywhere in this issue are now fixed. If you find a case where this is *not* true, please open a new issue with details.

It's true the accidentals shouldn't physically touch, but I was talking about the stacking order. The "octave rule" is one used by some publishers and guidelines but not others. Looking at the music on my shelves, it seems none of the major publishers (Schirmer, etc) obey any such rule. Octaves do align often because it just happens to work out that way, but when it doesn't, it doesn't, and they all seem OK with it. This goes for everything from my Schnabel editions of Beethoven piano sonatas to modern editions of late romantic music. And as I mentioned, the MPA guidelines make no mention of any such rule. So again, it's really a subjective thing.

But FWIW, I happen to subjectively think it's a good idea, and it does actually simplify handling of especially dense chords, so my new algorithms actually do enforce it, even to the extent of leading to otherwise sub-optimal results (as shown in comments to #25055: Poor accidental layout on large / complex chords). So the point is really moot.

Magnus, are you arguing just to argue? Have you tried the new code? Please test and report issues.

As I mentioned, it should be moot. Regardless of what any particular guideliens say or what any particular publishers do - and even a brief study of the literature will show tremendous variation - my alogirthms *do* follow the octave rule. Not just when it happens to work out that way as a side effect of following some other rule (which ends up being true way more often than not in tonal piano music), but always. As I said, I think it's a good principle, especially for music of the past century where unusual commbinations of accidentals can arise more often than in Baroque or Classical era music. So octave rule fans should have nothing to complain about.

Regardless of what Marc says, or what is misunderstood or even possibly mistyped, see the results. The proof is in the pudding Magnus. That's what is important.

You didn't answer my primary question: did you try the new code?

Magnus - no, I don't believe you are criticizing my algorithms. And I have nothing against getting at the truth either. I think we just disagree on the universality of accidental stacking guidelines in general and the octave rule in particular. You seem to be saying you have absolute certain knowledge that every publisher that has ever existed in the history of music engraving follows the octave rule to an extent *beyond* the simple fact that it happens to work out that way in most cases as a result of the common stacking algorithms. Whereas my own analysis of a considerable quantity of published music and engraving guidelines from respected sources finds that the variation is such that I see no evidence this the rule is as universally agreed upon as you seem to be suggesting. However, I have no "smoking gun" that proves otherwise, either.

I've done fairly extensive investigation into accidental stacking order issues lately and I'd be willing to share some of the observations that lead me to my conclusions, and I'd be mildly curious see what sort of evidence you might have to back up your own claims to posses of absolute certain knowledge of the universality of the octave rule. I'd be open to having that discussion in the right context, that is, but this isn't it. The issue is resolved; we are discussing trivia at this point. If you wish to demonstrate your proof for your claims of absolute certain knowledge of universality, feel free to stat a thread in the General Discussion forum (where it seems most appropriate), but we should let this thread die so the system can close the issue.

Either it's universal or its subjective. You can't argue against both claims; there is no middle ground. Take your pick, and continue the discussion elsewhere if you like.

Automatically closed -- issue fixed for 2 weeks with no activity.