Seconds between voices overlap

The png is not uploaded or not listed

This is also (still) an issue with unisons in two separate voices, which is actually quite common in notational practice.

Is this fixed?

Also, is this related (could you also comment if the behaviour is correct)?

Partially fixed in 1.0-- individual pitches no longer overlap if you enter, say, a C5 in one voice and a B4 in another, but if you add multiple notes to the second voice as the OP describes, then the notes involved in the second go right back to being on top of one another.

Thanks.

What about the nightly build?

I just asked because when I opened the mscz, it looked fine (unless you manually corrected it?).

However, you're right. It's still an issue.

it looks fine if you enter just one note in voice1 and one in voice 2 (with a second interval).
When entering another note (chord) in voice2 the error occurs (as if the wrong note in the chord is used for testing).

I took the liberty of raising priority - mainly because the workaround (suggested elsewhere) doesn't work.
See three screenshots attached:
Issue - shows unwanted overlap of notes
Workaround - removed via manual override of notehead position - stem of 2nd voice still wrong!
ToBe - it should be like this (as formatted by Lilypond)

NB. the manual override, to add note spacing, doesn't help either, since that is applied to all notes that sound simultaneously, not per voice!

afaik this issue still exists in Version 1.0 as well as recent nightly builds

A workaround is to double click the half note and to move it with the arrow keys.

thanks - very helpful indeed.
(one for the manual !)

I am trying to transcribe and transpose a musical number for a show I'm playing in. It has many overlapping voices, and I'm getting a case where the top and bottom voices on a staff overlap to the point of making the score unreadable.

Is there a workaround that can achieve the appearance of seconds between voices corrected.png in MuseScore 1.0?

Yes, as mentioned just above - double click the top note and uee srrow keys to move it. Once you've moved all notes in a chord, the stem moves too.

See also #14462: Note collisions in 2 voices if more than 2 notes present

Still an issue in 1.2 and trunk at R5478:
NOT FOUND: 01

Another duplicate reported by myself at #17929: Collision when making a chord with 2 voices

Another duplicate #17992: Multiple voices collide

Hello,

I'm seeing this in just a single voice in 1.2. Please see attached. Sorry if this is a dupe report; I didn't see another one in my cursory look around.

Easy to duplicate: just click on the F in the last chord in the 2nd measure and hit shift+E.

(Edit: and yes, shift-x works fine... but I shouldn't need to use it here, right?)

(Edit: and yes, present in the latest nightly build)

Tom

You have two F notes on top of each other. Remove one and the Eb will flip properly.

Thanks schepers. Would it not be considered a problem to be able to have two F notes on top of each other? Should I be allowed to do that in a single voice?

Thanks,
Tom

Well, I did have an issue submitted on this one for v1.2 but it wasn't addressed. In 1.2 you can have many stacked notes which will cause a variety of issues so try not to do that, even though it is "allowed". In the upcoming v2.0 you can no longer put multiple notes on each other quite so easily. One wouldn't think it would cause an issue but the algorithm to create the chord with the proper notehead directions gets quite screwed up with multiples of the same note.

Thanks schepers.

Reproduced this using the latest 2.0 nightly, r83da8e8. I'd eagerly and happily contribute a fix if someone introduced me to the layout code. Could somebody guide me as a totally newcomer contributor? What is the process of this?

The first thing to do is fork a repo of MuseScore from GitHub.

This enables you to work on MuseScore locally and then submit a pull request for inclusion into the main code.

I'm no expert on this, although I managed to do it on my own system.

There are plenty of guys around to give advice though.

I would also join the Developer mailing list if you haven't done that already.

@ChurchOrganist: Thanks, I'm already experienced with git and GitHub, I already contributed. But I didn't know about the mailing list, I'll try there.

Issue just came up again the German forum, http://musescore.org/de/node/23348

I checked with an older nightly (3e51505) and it seems fixed there

Doesn't seem fixed to me (git 6fa855c). Following the instructions from the OP, as soon as you add the second note to voice 2, the voice 2 notes move backwards so they sit directly underneath the voice 1 note and collide.

right, confirmed. so the overlap of second happens only if there are more notes in the chord, not just one. I tried loading the mscz attach to the first article and that seems to have worked.

So it looks to be about time to fix a 4 years old bug?

There must be at least two notes in one voice and one note in another voice, and there must be a collision between notes in both voices.

So it looks to be about time to fix a 4 years old bug?
If you are so impatient, your contribution is welcome.

You think waiting 4 years is impatient???

Hi Lasconic. There are many people contributing or trying to contribute to MuseScore. As you know, it is almost impossible to contribute to fixing bugs like this in existing code since a) the code is almost uncommented, b) there is no documented design and c) there is a minimal flow of information and very limited communication between the chief-developer and the rest of the world. [Correct me if I'm wrong, perhaps things have improved since I last contributed to code at the beginning of 2012].

I can see that a few people recently have hooked in new code, like Maurizio M. Gavioli, Tony Mountifield and Marc Sabatella, but no one, apart from yourself, has been in a position to tackle four-year-old problems like this one, simply because they can't invest the time to understand the algorithms.

As far as I understand it, modern software development is not about reverse-engineering undocumented code which is shifting underneath your feet. So if you're asking for contributions, please be aware which circumstances the contributors have to face. I noticed in the mailing list, that many people can't even take the hurdle of building the system, let alone understanding what they are doing to productively contribute to bug fixes. I am sure many people would love to contribute, if the circumstances were different.

The following link gives a list of the few people on the planet who have contributed to code. I can see that one new active member was recruited, Andrey M. Tokarev.
//github.com/musescore/MuseScore/graphs/contributors

What a great achievement this project has already managed - facility: I can write charts for my tunes and songs, for my band - music education: as we all struggle to express ourselves - an opportunity: to build a creative structure that is useful yet "free" (http://musescore.org/en/donate) - In-the-trenches coding experience: challenge and expression on so many levels, by so many people - community: >>> (hold mirror here) <<< .

What a great achievement this project has already managed, and it is still growing, it's still so young.

Werner, Thomas, Lasconic and everyone else (I know your name's not here, but you know who you are), thank you so much, and congratulations and "keep goin' baby!".

Don Naduriak

Let's keep it constructive. Software development takes time and programmers are no robots. I'm part of another open source software project, and even with well documented code, thousands of code contributors and lot's of financial resources, it can take years before some issues get fixed. Let's not push each others buttons and instead be supportive. This sometimes means to bite your tongue and type less. Thanks.

Agreed, and I apologize for apparently having pushed such a button, my whole intention was to push this issue back into sight.
Works both ways though, and just for the record: I received lasconic's reply as a plain 'STFU', while now, after a good night's sleep, I'm pretty certain it wasn't meant that way ;-)

Just confirming this with a screenshot from a recent nightly build 6ba4ef6.

And to help people find the workaround for this bug - double click the top note and use arrow keys to move it. Once you've moved all notes in a chord, the stem moves too.

(Although, in this specific nightly build, there's a bug with the "the stem moves too" part. It works in 1.3. I'll go make another issue for that.)

The right way to do it for a chord in current development version is to use the inspector F8 and change the Horizontal offset of the chord. Using the arrow keys will only move the note and not the chord (except if it's a one-note chord)

just came up again in http://musescore.org/en/node/23859

MarkRS: are you working on this? I was looking at the code and think I would like to get this. Feel free to reassign if you've invested a lot of time and are getting close.

This turned out to be pretty involved to really get right, with lots of different cases to consider - almost all of which were not handled correctly but need to be handled differently from each other. A number of these cases are covered in existing issues, but quite a few were not. Anyhow, I'm happy to say I have a fix for everything I could think of in this area! Here are the results for a variety of cases, and according to my understanding, these should all be correct:

A convenient side effect of my code is that accidentals are also handled well in most of these same cases, whereas they were usually way off. But I didn't actually touch the accidental layout code - these improvements came for free with my changes to the layout of the chords themselves. I know there are a few issues with accidentals that didn't magically fix themselves. We may also want to look at layout of dots in these cases. I could either do all that before issuing a pull request on this, or submit the PR sooner and tackle accidentals and dots later (or let someone else have at it).

Here is my branch:

https://github.com/MarcSabatella/MuseScore/compare/3325-seconds

Feedback welcome.

Since I had to spend some time wrapping my brain around the existing code (which is leveraged heavily through here - just refactored and with new code added), I took advantage of the opportunity to comment it liberally to make things easier for whomever might want to look at this code in the future.

For grins, here is how that sample used to look:

Here are three scores I put together as test cases:

conflict.mscz - the score (produced in 1.3) for the example I posted above

seconds.mscx - this was what I actually used most during development

offset-notes.mscz - a test case I put together for a related issue (fine tuning the spacing)

BTW, I picked a few of the specific chord combinations to run through LilyPond, Finale, and Sibelius. I'd say all three were miles ahead of MuseScore 1.3, but with this change we would leapfrog Finale and Sibelius (both of which produce less-than-ideal results on several of these cases). Really, the results from MuseScore with my code are more or less indistinguishable from LilyPond except for the specific amounts of offset applied. I opted for somewhat tighter spacing, more in keeping with Gould's examples. LilyPond's is looser in some places - putting more space between the upstem and downstem notes here and there. But again, the same basic arrangement of notes.

Here is the output from offset-notes with my changes.

I think I got the spacing looking good / consistent. It would be a very simple matter to up the offsets if we decided to go with the looser LilyPond-style spacing over the tighter Gould-style. Or even have a couple of style parameters.

These is a major step forward Mark.

Have you sent in a pull request?

see PR #742

I'm not sure about the first chord in measure 10. Shouldn't that be one directly over the other?

The rest all look good to me.

I wondered that too, but even my wife said it was good. The top chord left note and the bottom chord right note are correctly on top of each other, the other two notes are flipped due to proximity. Strange looking, but seems correct. The stems shouldn't align in this case.

Just to add my voice to the choir, Marc... good job! This has been one of the most annoying bugs I've had to fight with on many scores.

In the promenade example in 2.0, measures 9-12 but especially 9, I see some interesting collisions between accidentals and stems. Was this there before?

Thanks for the feedback!

Regarding the rest failure: I haven't tried to build and run tests locally, so I can't see if it crashes for me. Seems likely from the name of the test to be my fault. To be honest, most of my testing has involved only voices 1 & 2, with just a few spot checks involving voice 3. I will look into this later today.

Regarding measure 10 - yes, that is correct. The rule is, the non-displaced notes should line up.

Regarding accidentals in Promenade - yes, that sort of problem was there before. You can see a very clear example of it if you try adding a flat to the B in measure 4 of my test. This much was a regression against 1.3 that was already present before my changes, and it is the main pre-existing issue I knew about going in that I didn't try to fix yet. But the problem is exacerbated in Promenade by the fact that this measure had some manual adjustments applied in an effort to workaround the basic problems in note layout, this manual adjustment is no longer needed and ends up being counterproductive. I haven't decided how to best deal with this in general. My inclination is to throw away all manual adjustments to note position in cases where I know my code will produce different results from previous versions.

BTW, as an example of what I mean when I say that major improvements in accidental placement came for free with my changes, here is one typical example.

Before: After:

Again, I didn't touch the accidental layout code; just sorting the list of notes internally before calling the accidental layout code improved this. But there are indeed still some issues with accidentals (and dots) to deal with. Even the "after" result above is still not ideal - the accidentals toward the top of the chord can be closer to the noteheads. But things are at least in the right relative positions, and here too, the above is at least better than Finale.

I believe the offset could be even smaller. See this example and Gould p 54.

another small detail I noticed:
measure 24 beat 3
measure 25 beat 1

The down stem doesn't line up exactly with the left side of the note. It's like 1 pixel too far to the right.

That might a be zoom-related artifact.

Those apparently stem alignment issues are definitely just zoom artifacts. Looks fine at full magnification.

But FWIW, that particular chord - measure 24, beat 3 - actually shows why lasconic's example in response #54 seems so wide, and this is something I will try to deal with. My code does not currently take the asymmetry of the notehead into account, so I am allocating enough room for a second that goes up left to right, whereas due to the shape of the noteheads, seconds that go down left to right don't need as much space. You can see that in measure 24 beats 3 - the bottom notes of each voice have space to spare, but the top notes are practically touching already, because the noteheads themselves are slanted up left to right.

I'm not sure if there is a good (and fast!) way to account for that accurately based on font metrics, but I will look into coming up with second-up and second-down values that work well for the fonts we support.

I've made a few improvements, including a fix for the test that failed, tightening the space in the example from #54 mentioned, and handling one case (the only one I've discovered so far) where even LilyPond gets it wrong. Code is checked into my branch.

Measure 31 is the one LilyPond gets wrong, at least in my opinion - the upstem doesn't clear the whole note.

On closer examination, however, there really *is* a stem alignment issue. Not on any of downstem chords, but on *all* of the upstem ones. You can see it on this same measure, at least if you zoom in enough. This is not a result of my changes; I see the same in a nightly build from a couple of weeks ago. It's most noticeable on half notes (minims), and you don't need multiple voices or chords to see it - just a single upstem half note. The stem is a few pixels too far left, so the right side of the notehead protrudes on the far side of the stem. Switch to Bravura and now the stem is too far right, to the point where the notehead is practically detached. Again, this is true with or without my change - but I wonder now if the problem isn't in the same area of code I am dealing with? Or if it an issue with both fonts?

I've updated my code to handle dotted chords. There is a lot of variety in how publishers do this, and Gould in Behind Bars shows a number of acceptable options. MuseScore normally expects all dots for a given segment to align vertically, so layouts where chords in different voices for the same staff have different horizontal positions are harder to achieve. Luckily, this option is supported by Gould, mentioned as being good for "cramped conditions", so I went with it.

So the end result is that when we have a second between voices (or any other situation that requires a chord to be offset to the right), dots on the leftmost chord are placed between the chords if there are not dots on the rightmost chord, but all dots are placed next to the rightmost chord if it has dots. As they say, a picture is worth a thousand words:

Again, feedback welcome. Note that I have yet to deal with the question of *vertical* position of dots. That is handled in a completely different section of code, which I plan to look at later. Also, measure 41 above is a very special case: it's actually four voices, one note per voice, with dots in only one of the two upstem voices and only one of the two downstem voices. The results are admittedly not pretty, but it is a very unusual situation.

Marc, I've been playing with your code, trying things out. I'm not sure if this is related to your changes, but see the following pic:

Are the ledger lines too long, or are the accidentals too close to the ledger lines because they blend together sometimes. In the examples I've found, there is always a little space between the ledger and the accidental. This is especially true for the second and third notes.

Also, with these changes, the sample score Promenade needs to be updated. All the manual adjustments need to be removed because those measures with adjustments don't look good anymore. Even all my old scores can now have the manual adjustments removed because notes/chords/voices, accidentals and dots all place much more logically.

I'm still working on improving accidental placement and hope to post an update soon. But FWIW, the collision of accidentals with ledger lines is not my doing - that was there already in previous 2.0 builds.

In 1.3, ledger lines were shortened to avoid these collisions. I don't know if that's the best answer, nor do I know the best way to make that happen if we decide that is the way to go (there may be a special SMuFL glyph for that?). But it would be very easy to tweak my code so that accidentals clear ledger lines if we decide that is the way to go.

As for how to handle 1.3 scores, my goal - and I can hardly believe it, but I'm almost there! - is that almost no manual adjustment will ever be necessary after basic note entry. Noteheads, stems, dots, accidentals, and ties will virtually always be positioned well by default. So my thinking is that upon reading a 1.3 score, I will have MuseScore automatically strip away all manual positioning of these elements, since as you've noticed, those manual adjustments won't make sense anyhow.

Manual adjustments will still be needed for slurs, dynamics, etc - but not for basic note entry except in the most oddball corner cases.

I would tweak the accidental placement, only slightly. Just enough for a crack of space to show, like 1/32.

I believe I have accidentals working about as well as I would like for now. I made a number of improvements, more than I initially planned on but all worth doing.

I've attached the results using the test file I've been developing. Here are some of the main things to note:

* Accidentals on displaced notes no longer overlap the chord (regression introduced earlier in 2.0 development). See ms. 10-12.

* Accidentals do not collide with ledger lines (regression introduce earlier in 2.0 development; we may back this change out if we decide to shorten ledger lines as we did in 1.3). See ms. 1.

* Accidentals now are placed close to the main chord tones even if there is a second somewhere else in the chord (improved over 1.3). See ms. 5-7.

* Better detection of when accidentals can partially overlap (improved over 1.3). See ms. 13-21.

* When two accidentals are separated by a seventh and come close to touching, the lower one is displaced to the right slightly so the vertical strokes don't appear to align (improved over 1.3). See ms. 13-21, first chord of each measure.

* Double flat, double sharp, and microtonal accidentals are spaced reasonably well (improved over 1.3). See ms. 22.

* "Zig zag" stacking order used rather than "top, bottom, diagonal" (improved over 1.3). See ms. 24-25. I wasn't going to do this, but I got inspired by an article lasconic pointed me to on the Steinberg site. Coincidentally, they've been working on the same issues recently, and they showed a series of comparison that made it clear we needed to do this. Plus my other changes had the side effect of making it very easy to change stacking order.

The end result should be more logical layout with fewer collisions - and at least in some cases, less wasted space as well.

At this point, aside from responding to issues that arise, I think I'm finally done with chord layout. Noteheads, dots, and accidentals are all working well. There are still issues with the amount of space allocated before the first chord of the measure, with the vertical position of dots when seconds or unisons are involved, and with the vertical position of short ties. I may look at those next, but those are all handled in different parts of the code than what I've been messing with here. So I'm ready for a final review should anyone want, and then as far as I am concerned the code is ready to merge.

Regarding measure 5-7, see #22642: Horizontal positioning of accidental incorrect if in chord with adjacent notes
For the stacking see #1464: Faulty vertical alignment of accidentals at chords

Measure 25, first chord, isn't there room for the sharp on the A to be next to the A, rather than far on the outside?

Measure 3, it's hard to tell but some of the sharps seem far to close to the notes. Maybe it's a zoom or PNG artifact. I will have to integrate your latest changes and test.

I didn't change anything about the basic distance from accidental to note. This is a configurable style setting, Style / General / Notes, and I have set to the default, 0.22sp. I think we're seeing a zoom artifact here.

Regarding measure 25, this is a place where the zig zag stacking algorithm is clearly sub-optimal in itself. Since there is a whole other issue specifically for stacking order and I posted something there earlier, I'll direct you to that for more background:

http://musescore.org/en/node/1464#comment-97175

For the record, the result for this measure in 1.3 ("top, bottom, diagonal") is worse still for measures 24-25:

While the "zig zag" algorithm I just implemented beats "top, down, diagonal" here, it doesn't beat it by much, and there is clearly still room for improvement. But while it's often pretty easy for a human to spot opportunities to optimize the arrangement on a case by case basis, devising an algorithm that produce close-to-optimal results automatically is quite a challenge. Hence Daniel Spreadbury's blog article.

The good news is, the cases where you get these bad results virtually never come up in the real world. You need there to be pretty big chords with lots of accidentals all on the same staff. Realistically, most of us only have five fingers; chords that big on a single staff are quite rare :-)

I'm continuing to test all the changes I've made over the past couple of weeks - the original issue with seconds between voices, also ties and accidentals. So far so good. I fixed a couple of things I found along the way, and submitted issues for problems I found in other aspects of layout. If anyone has any scores you think would make particularly good test cases, please send them my way.

Meanwhile, here is a page from a score of mine that required fairly extensive manual tweaks to note and accidental position when I originally entered it (in 1.2). Now, no manual adjustments whatsoever are really needed (not that one couldn't still improve it slightly):

Here for reference is the same unadjusted score as rendered in 1.3:

1.3 rendering

I closed the old PR and re-submitted so I could rebase the code. This is the only solution I know and trust to dealing with the complaints I get about not being able to fast-forward). I also added a bunch of vtests.

Here is the new PR:

https://github.com/musescore/MuseScore/pull/770

It is possible to rebase an existing PR...

Maybe so, but I haven't figured out how. In my experience, one I rebase a branch, GitHub won't let me push it any more, giving me an error about the head being out of sync or whatever. And it tells me to read the note about fast forwards in the help, but nothing in that note seems even marginally related to the actual situation.

Seems this discussion should maybe go offline, though...

git push --force

Or, similarly,
git push -f

Is that safe in this situation, though? The description in the help under that note on fast-forwards makes it seem otherwise, which is what I meant when I said that deleting and recreating the branch is the only solution I trust.

I think it is. It is just bad when someone else is already working on merging the PR

This may be a presumptuous request, but could this be PR be merged as is? Marc will certainly continue to push changes. This is, to me, one of the most important changes in months and I really want to be able to continuously test the changes. I don't know how to do that as it sits in a PR.

Fair enough. We were more or less ready to merge yesterday, but concerns were raised about the degree to which the changes were font-dependent. I improved this some last night, and I'm about to (within next few hours) commit another change along with hopefully working vtests. At that point I'll consider it ready to merge again. So, by end of (my) day today, possibly within the hour. OK?

That's just speaking for me of course. I can't do the actual merge. But I'd rather the merge waited just one more commit. Then as soon as practical afterwards is great by me.

OK, I just pushed the commit I was working on and would be happy to see this all merged whenever convenient.

Note I have not included code to strip away manual positioning adjustments in older scores; I am not sure if it's really the right thing to do or what the safest way to do it it. So to see the new layout correctly on older scores, you'll want to select all notes (Ctrl+A won't work - it selects to much), Ctrl+R, set Mirror explicitly to Auto by setting it Lefty and then back, then also select all flats, sharps, and naturals, and Ctrl+R them too.

Could be a preference setting, 'ignore user modified positioning of notes and accidentals when importing 1.x scores'

The problem with doing the select all notes & reset is that it resets everything (custom beams, note flips, etc) and now the whole score needs to be checked. Since I think it's understood that not everything will survive 100% when loading 1.x scores into 2.0, and this change resolves a whole host of unnecessary adjustments, I have no problem removing custom note, accidental and dot adjustments.

If such a preference were used, I would set it ON by default.

I'd probably set it to on too, but I'd want the factory default to be off.

Good point about beams and so forth. So don't use Ctrl+R if you've done those kinds of adjustments. Instead use the Inspector. There are convenient reset buttons next to the horizontal and vertical offset fields. Eventually, if we do something automatically, we'd want to be careful to only strip off certain adjustments (chord/note offsets, mirroring, accidental offsets).

One idea that has been suggested is to have 1.X scores load as Untitled, so you are prompted to give them new names when you save. There could also be a dialog that comes up on each score upon open, prompting you as to how you want it imported - whether to strip off custom adjustments or not, maybe anything else where there is a question as to how to import. This is basically what Finale does when it opening scores too old to trust. This might be better than an option, as it's likely to be something you'd want to consider case by case.

BTW, since lasconic is apparently travelling, it should be possible to build from my branch yourself. I posted the link before, and despite deleting and recreating it the URL hasn't changed:

https://github.com/MarcSabatella/MuseScore/compare/3325-seconds

I don't know the exact sequence of steps to fetch from this and incorporate it into your builds, but I know it's possible.

Fixed in 238570e263

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