Fix #305487: Invisible accidentals take space #6100

mattmcclinch · 2020-05-20T12:51:21Z

Resolves: https://musescore.org/en/node/305487

MarcSabatella · 2020-05-20T14:01:13Z

What would you think about changing those tests from visible() to addToSkyline()? Admittedly this isn’t the actual skyline, but also I probably didn’t choose the best name for that function, as I think I use it a couple of other places where it isn’t literally about the skyline.

Anyhow the point is to also disable these same things if autoplace is turned off. The advantage would be allowing accidental on a note in one voice to tuck under/over notes in other voices (they already do for rests even without disabling autoplace).

mattmcclinch · 2020-05-20T14:10:10Z

I think the point of #305487 is that invisible accidentals should not take space, but I could be wrong. Testing for addToSkyline() instead of visible() is not the answer, but I could see testing for both.

mattmcclinch · 2020-05-20T14:17:25Z

Oh, I see. addToSkyline() returns false if the element is invisible. Very well then. I will modify this PR accordingly.

MarcSabatella · 2020-05-20T15:15:38Z

Of course I’ll want to test to make sure this really does work as expected, I hadn’t originally thought of maki g the change anywhere but layoutPitched(). I’ll look into this more later today. Originally I had punted in doing anything with that issue thinking it made more sense to wait for MuseScore 4, but this could actually be a good opportunity to do just this much and make a difference for those who care about such things.

Harmoniker1 · 2020-05-20T18:04:38Z

@MarcSabatella What is "skyline"?

MarcSabatella · 2020-05-20T19:11:14Z

#6100 (comment)

The skyline is the heart and soul of autoplace. It’s the shape you get if you draw a zigzag line across the top of the staff, accounting for all elements that are above sticking out from the staff. We do most collision detection against this shape, not the individual elements themselves.

MarcSabatella · 2020-05-20T19:26:29Z

I think we should also add a check in hasAccidental(), a static function in measure.cpp. Otherwise, if the first note of a measure has an invisible accidental, we use the barline-to-accidental style setting rather than barline-to-note.

MarcSabatella · 2020-05-20T19:27:55Z

Dang it, I added some review comments, or so I thought, then apparently lost them somehow. Will re-add now.

Jojo-Schmitz · 2020-05-20T19:46:01Z

I don't understand how your current changes could possibly cause those mtest failures in the guitar pro tests? See https://travis-ci.org/github/musescore/MuseScore/jobs/689317166#L4353-L4917

Edit I see, #6101 seems the culprit, brown bag for me... (and for a quite stupid GP 3,4,5 import)
Should be fixed with #6103

MarcSabatella

I left review comments. The most important is the one regarding the accidental stacking code - the PR as is will lose accidentals "completely" (as far as the layout is concerned) on reload.

MarcSabatella · 2020-05-20T19:42:13Z

libmscore/layout.cpp

@@ -841,7 +841,7 @@ void Score::layoutChords3(std::vector<Note*>& notes, const Staff* staff, Segment
      for (int i = nNotes-1; i >= 0; --i) {
            Note* note     = notes[i];
            Accidental* ac = note->accidental();
-            if (ac && !note->fixed()) {
+            if (ac && ac->addToSkyline() && !note->fixed()) {


This doesn't work correctly - it causes the layout to be skipped entirely. That means, among other things, the invisible or non-autoplaced accidental will disappear completely on save/reload.

Dealing with this will be tricky because of the interdependencies between accidentals on a single chord (which is what this code - some of the very first I contributed to MuseScore! - is dealing with). Ideally we want to still place the accidental where it would have been otherwise if it were visible and autoplaced, but we would not let this affect the position of other accidentals. But I'm not sure how feasible that is here.

The easiest answer would be to lose this particular change. This would be fine for chords with a single accidental.
But the downside would be, a single invisible accidental in the middle of a chord with multiple accidentals would leave a "gap" in the accidental stack, just as it does now.

Another possibility is to start the block so we still get the layout, but add an "if (!ac->visible()) continue;" right after the layout. Well, might be good to set some explicit x position, otherwise it will end up staying where it is when you first make it invisible, but then become 0 on save/reload. This wouldn't be acceptable for visible accidentals with autoplace turned off, though - they still need to stack normally.

Anything else would probably require deeper change to the accidental stacking algorithm further below, and I'm not even sure it would be possible to define a more sensible behavior.

MarcSabatella · 2020-05-20T19:44:43Z

libmscore/note.cpp

@@ -3429,7 +3429,7 @@ Shape Note::shape() const
      Shape shape(r, name());
      for (NoteDot* dot : _dots)
            shape.add(symBbox(SymId::augmentationDot).translated(dot->pos()), dot->name());
-      if (_accidental)
+      if (_accidental && _accidental->addToSkyline())


For the purpose of making sure accidentals can tuck over/under other notes, this is not needed. Which is to say, it could be visible() instead of addToSkyline(). As it is, this change means non-autoplaced accidentals can not only tuck over/under, they can also collide with previous notes. I guess that's expected, although not what I was originally thinking might be nice. I suppose it's more of a hack, though, so I'm fine leaving this as you have it. Just wanted to mention it in case it sparks any additional thoughts.

MarcSabatella · 2020-05-20T19:46:13Z

libmscore/note.cpp

@@ -3442,7 +3442,7 @@ Shape Note::shape() const
      Shape shape(r);
      for (NoteDot* dot : _dots)
            shape.add(symBbox(SymId::augmentationDot).translated(dot->pos()));
-      if (_accidental)
+      if (_accidental && _accidental->addToSkyline())


FWIW, I wonder if we could lose this NDEBUG duplication? Right now it buys us some better debug info on the shapes when compiling in debug mode, without a performance penalty otherwise. But maybe there is a less error-prone way of doing that? Way too easy for these two sections of code to get out of sync.

MarcSabatella · 2020-05-20T19:46:49Z

libmscore/note.cpp

@@ -3442,7 +3442,7 @@ Shape Note::shape() const
      Shape shape(r);
      for (NoteDot* dot : _dots)
            shape.add(symBbox(SymId::augmentationDot).translated(dot->pos()));
-      if (_accidental)
+      if (_accidental && _accidental->addToSkyline())
            shape.add(_accidental->bbox().translated(_accidental->pos()));
      for (auto e : _el) {
            if (e->autoplace() && e->visible()) {


Minor nit, not your code of course, but this could now be addToSkyline() too if we wanted.

MarcSabatella · 2020-05-20T20:23:06Z

FWIW, since I was implementing and testing my suggestions as I went along, here's my version. Main question to me would be what to actually assign as the x position for invisible accidentals. I used -width which places them just to left of the notehead. We could try to get fancy and leave a margin, account for ledger line, etc - or not.

https://github.com/MarcSabatella/MuseScore/tree/noauto-accidentals

This skips allocating space for accidentals if marked invisible or no autoplace. For accidentals marked invisible, they also don't affect stacking of multiple accidentals.

Jojo-Schmitz · 2020-05-25T15:26:53Z

For some strange reason GitHub shows the Travis job as Pending, but that finished successfully

mattmcclinch force-pushed the 305487-invisible-accidentals branch from 060a5b9 to 792110f Compare May 20, 2020 13:53

mattmcclinch force-pushed the 305487-invisible-accidentals branch from 792110f to 9d82ad8 Compare May 20, 2020 14:19

mattmcclinch force-pushed the 305487-invisible-accidentals branch from 9d82ad8 to 116ccc9 Compare May 20, 2020 16:18

MarcSabatella suggested changes May 20, 2020

View reviewed changes

mattmcclinch force-pushed the 305487-invisible-accidentals branch from 116ccc9 to 0cd1b49 Compare May 21, 2020 01:41

fix #305487: invisible accidentals take space

a881987

This skips allocating space for accidentals if marked invisible or no autoplace. For accidentals marked invisible, they also don't affect stacking of multiple accidentals.

mattmcclinch force-pushed the 305487-invisible-accidentals branch from 0cd1b49 to a881987 Compare May 22, 2020 13:34

MarcSabatella approved these changes May 26, 2020

View reviewed changes

MarcSabatella mentioned this pull request May 27, 2020

MuseScore 3.5 Beta. PRs to be merged #6027

Closed

12 tasks

anatoly-os merged commit 4a053fc into musescore:3.x Jun 2, 2020

Jojo-Schmitz mentioned this pull request Jul 23, 2020

[MU4 Issue] PRs from 3.x to be merged into / ported to master #6079

Closed

29 tasks

anatoly-os added a commit that referenced this pull request Aug 7, 2020

Manually merged #6100 to master

6a8100d

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix #305487: Invisible accidentals take space #6100

Fix #305487: Invisible accidentals take space #6100

mattmcclinch commented May 20, 2020

MarcSabatella commented May 20, 2020

mattmcclinch commented May 20, 2020

mattmcclinch commented May 20, 2020

MarcSabatella commented May 20, 2020

Harmoniker1 commented May 20, 2020

MarcSabatella commented May 20, 2020

MarcSabatella commented May 20, 2020

MarcSabatella commented May 20, 2020

Jojo-Schmitz commented May 20, 2020 •

edited

Loading

MarcSabatella left a comment

MarcSabatella May 20, 2020

MarcSabatella May 20, 2020

MarcSabatella May 20, 2020

MarcSabatella May 20, 2020

MarcSabatella commented May 20, 2020 •

edited

Loading

Jojo-Schmitz commented May 25, 2020

Fix #305487: Invisible accidentals take space #6100

Fix #305487: Invisible accidentals take space #6100

Conversation

mattmcclinch commented May 20, 2020

MarcSabatella commented May 20, 2020

mattmcclinch commented May 20, 2020

mattmcclinch commented May 20, 2020

MarcSabatella commented May 20, 2020

Harmoniker1 commented May 20, 2020

MarcSabatella commented May 20, 2020

MarcSabatella commented May 20, 2020

MarcSabatella commented May 20, 2020

Jojo-Schmitz commented May 20, 2020 • edited Loading

MarcSabatella left a comment

Choose a reason for hiding this comment

MarcSabatella May 20, 2020

Choose a reason for hiding this comment

MarcSabatella May 20, 2020

Choose a reason for hiding this comment

MarcSabatella May 20, 2020

Choose a reason for hiding this comment

MarcSabatella May 20, 2020

Choose a reason for hiding this comment

MarcSabatella commented May 20, 2020 • edited Loading

Jojo-Schmitz commented May 25, 2020

Jojo-Schmitz commented May 20, 2020 •

edited

Loading

MarcSabatella commented May 20, 2020 •

edited

Loading