Faulty vertical alignment of accidentals at chords
S4 - Minor
In the attached MuseScore example the program aligns the upper natural and the sharp and sets the lower natural to the left. MuseScore should instead align the naturals and put the sharp to the left like in the other example attached.
|Accidentals at chords in MuseScore.PNG||122.96 KB|
|Accidentals at chords.PNG||43.04 KB|
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.
David! Would you like to give a reference to or formulate the alignment rule MuseScore is following in this case?
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).
Many thanks, Werner. Chord number 13 in your example is however incorrectly set according to both me and J Gedan, which of course affects the accidental placement; see attachment and page 17 in http://www.pian-e-forte.de/texte/pdf/notenschreiben01.pdf. For chords number 14 and 15 I would prefer what's in my version of the example for those chords though the difference is not big. As usual I made my example with Igor Engraver, but it took some editing to get the attached result.
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.
I have now read Standard Music Notation Practice and I can agree with almost everything in that text. The rule mentioned for accidentals at chords was clear, I think. A little elaborated, but probably not sufficient for an algorithm, it is something like this:
1. The highest accidental in normal position next to its notehead if it does not encroach on a note.
2. The first lower accidental that does not encroach vertically on the highest accidental is vertically aligned with it.
3. The second lower accidental that does not encroach vertically on the accidental in number 2 is vertically aligned with it (and the highest).
4. The other accidentals are displaced to the left starting with the first lower accidental from the top one that encroaches vertically on it.
Can this be refined and translated into computer language and be understood by a machine?
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.
Regarding Guifre's D flat major seventh chord I am here attaching images of the default output from the notation program Igor Engraver and two manually edited variants I prefer over the default, especially number 2.
To Chen Lung's E flat diminished seventh chord I attach Igor Engraver's default output and two variants of which I think I prefer number 1.
What's incorrect with "faulty"?
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,
Daloonik's issue is actually another example of faulty vertical alignment. However, the 45 degree angle is correct. What MuseScore is missing is rule number 2 in my comment number 6. Attaching the default output in Igor Engraver that takes this rule into consideration.
It is rather complicated, but vertical alignment requires the objects to be in the same horizontal position.
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.
If your adjustment, Lung, of Guifre's example is in accordance with Elaine Gould's recommendations she really should be behind bars from a music typesetter's perspective.
Here is LilyPond, which might be better in some aspects, but I don't think it's completely right either.
Werner or David :D?
Earlier you said Lilypond yielded the same result as my Variant 2. The attached PDF is something quite different. By the way, please use PNG for attachments.
Okay. Here are PNG's.
Thanks. The problem with the accidentals layout of "My example (Lilypond)" is that it doesn't let the accidentals for the interval of the second (d double flat - e flat) follow the layout of the notes. The same is true for "Guifre (Lilypond)", and that example also sets the naturals for C5 and C6 too far from the notes.
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?
Jojo, may I ask you to attach a PNG file depicting the problem?
Thanks for the image. The first accidental layout is wrong; the second is correct. The second accidental layout should be used also in the first example with the two notes divided on two parts. There is obviously something missing in Musescore's code when it comes to accidental layout for separate parts on one staff.
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:
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:
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:
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.
Marc: "In fact there was nothing particularly *wrong* about the actual example that started the issue, and some of the well-respect guidelines would lead to exactly that result (MPA, for example)."
The starting example showed two collisions between accidentals and a violation of the octave rule. No well-respected guideline should lead to such a result.
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.
Marc: "[...] but I was talking about the stacking order."
But there was something wrong also with the stacking order in the original example.
Marc: "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."
No, it is not that haphazard regarding advanced engraving. The octave rule is at times overridden, but it is not done randomly.
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.
Schepers: "Magnus, are you arguing just to argue?"
No, what makes you believe that? I just want correct to be correct. If Marc or anyone else says something that is not correct or true I point that out, but this is obviously very annoying to several contributors here, and that is really a pity.
Marc, do you believe I have criticized your algorithms?
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?
Schepers: "That's what is important."
Then why obscure and confuse things with incorrectness?
Schepers: [...] did you try the new code?"
No, I didn't, since my issue wasn't about the algorithms. Now you may answer my questions.
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.
Marc: "Magnus - no, I don't believe you are criticizing my algorithms."
Marc: "And I have nothing against getting at the truth either."
Marc: "I think we just disagree on the universality of accidental stacking guidelines in general and the octave rule in particular."
No, I never addressed the universality.
Marc: "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."
No, I do not seem to be saying such a thing. Why this gross misrepresentation or misunderstanding? Furthermore, I believe the skilled engravers of the past never talked about algorithms.
Marc: "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."
Again, I have not addressed the universality.
Marc: "[...] 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."
Spare us your sarcasms, Marc, and for the third time, you keep repeating your misunderstanding or misrepresentation.
Marc: "The issue is resolved; we are discussing trivia at this point."
The issue is perhaps resolved, but that wasn't why I pointed out your false statements.
Marc: "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."
Ha, ha, ha! This is just ridiculous! Now, you not only say I seem to be saying a thing I am not saying, but you assert that I am saying it.
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.
Marc: "Either it's universal or its subjective."
No, Marc, you have misunderstood even that.
Automatically closed -- issue fixed for 2 weeks with no activity.