Voice 2 note stems face wrong way when noteheads made invisible

See https://musescore.org/en/handbook/3/noteheads#shared-noteheads for a workaround (and the proof that what you descibe here should work too)

I wonder when that broke, 3.5.2 has that bug already.

I have an idea of the commit that broke this. Easy enough to guess...
One more painful side effect, (somewhere in April 2020 e.g. ...)

Can you be more specific on this, please?

Really sure you have no idea?! I doubt it :)

Before this commit:

After (and now):

No, I don't. I do remember a change reg. collapsing matching rests, is that what you mean? I'd still not know what commit that might have been.
(Hmm, no, can't be that)

"I do remember a change reg. collapsing matching rests, is that what you mean? "
Of course! April 20, 2020
(if I mistaken something, between April 15 - result of first image - and April 20 anyway - second image)

The above image is not collapsing matching rests, at least not all (just 2 out of 6). And please name the commit...

Whatever, it it is a change from April 2020, it got to be a 3.5 regression.
Still would like to know the exact commit

"The above image is not collapsing matching rests, at least not all (just 2 out of 6)"
Of course ! These are the only two where I activated invisibility (V), as for the C quarter note, Voice 2, the next measure.
For the commit, Iikely this one I guess: https://github.com/musescore/MuseScore/commit/e9864d1e83db9b84e247b9545…

So the fix for #294085: All elements set to normal position if all rests in voices other than voice 1 are deleted, 472cb6b
Thanks for digging into this ;-)

This issue is not caused by the commit in question. It already existed in 2.3.2 and in the earliest builds of MuseScore 3. If the half rest in voice 2 were to be deleted or made invisible, or if the pattern were to be repeated throughout the measure, or if the score were in 2/4, you would get the same undesired result, no matter which build of the software you are using. For the real cause of this issue, see https://github.com/musescore/MuseScore/pull/1692.

The workaround is simply to flip the note immediately after making it invisible.

So a 2.3 regression, first showing in 2.3rc

Please see:

With (April 15, 2020) : b30f199

With (April 20, 2020): b2c71cd

@cadiz1 Sure, but I wonder if you understand what I was saying. If not, I doubt I could explain it any better than I already did.

@Jojo-Schmitz PR #1692 was merged on Feb 2, 2015, before even 2.0rc.

Ah, I didn't unfold' the list of tags, so only ssaw the 1st and last v3.6.2 … 2.3rc in the list, but indeed there's every 2.x and 3.x in that list.

And I guess while the changes fom https://github.com/musescore/MuseScore/pull/1692 are the root cause, those from https://github.com/musescore/MuseScore/pull/5371 made it just worse

I think this is the inevitable effect of combing two very good improvements - the one I made that @mattmcclinch referenced ( https://github.com/musescore/MuseScore/pull/1692), and the one Matt made that @cadiz1 referenced (https://github.com/musescore/MuseScore/pull/5371). I would claim both of those were good and desirable changes in general, but they do have this unfortunate side effect when combined. And it's definitely more my fault than Matt's.

Thinking through the reason for my original change, it was so a completely invisible voice 2 would not interfere with voice 1 stem directions. But voice 2 is not completely invisible here - only the noteheads are invisible. The stems are still visible. So basically, the original check I made wasn't strong enough. In particular, here:

https://github.com/musescore/MuseScore/pull/1692/files#diff-2c9ae7fdc5d…

As the comment says, the algorithm is designed to "consider chord visible if any note is visible". That's not good enough. It should also be considered visible if the stem or any other part of the chord is visible. And probably there is better way of checking that - like, the chord should probably already be managing this.

Checking for stem (and hook) visibility there is not helping the issue though, I tried this:

diff --git a/libmscore/measure.cpp b/libmscore/measure.cpp
index 3a5d552a8..729707588 100644
--- a/libmscore/measure.cpp
+++ b/libmscore/measure.cpp
@@ -2793,7 +2793,11 @@ bool Measure::hasVoices(int staffIdx, Fraction stick, Fraction len) const
                         if (cr->tick() + cr->actualTicks() <= stick)
                               continue;
                         bool v = false;
-                        if (cr->isChord()) {
+                        if (cr->isStem() && cr->visible())
+                              v = true;
+                        else if (cr->isHook() && cr->visible())
+                              v = true;
+                        else if (cr->isChord()) {
                               // consider chord visible if any note is visible
                               Chord* c = toChord(cr);
                               for (Note* n : c->notes()) {

And the attached test score

I can't imagine cr->isStem() would ever return true, would it? I mean, either it's a ChordRest or a Stem, but it can't be both. Probably you mean c->stem(), in the clause where we've already ascertained it actually is a chord.

Duh! Dumb idea...
OK, then let's try this:

diff --git a/libmscore/measure.cpp b/libmscore/measure.cpp
index 3a5d552a8..691b831f9 100644
--- a/libmscore/measure.cpp
+++ b/libmscore/measure.cpp
@@ -2802,6 +2802,9 @@ bool Measure::hasVoices(int staffIdx, Fraction stick, Fraction len) const
                                           break;
                                           }
                                     }
+                              // same if stem or hook(s) are visible
+                              if ((c->stem() || c->hook()) && c->visible())
+                                    v = true;
                               }
                         else if (cr->isRest())
                               v = cr->visible() && !toRest(cr)->isGap();

Works with the above sample score

See https://github.com/musescore/MuseScore/pull/8011 (for 3.x)
and https://github.com/musescore/MuseScore/pull/8012 (for master)

Does this PR also solve this case? Namely: when you hide the rests in Voice2 (here half rests, see the attached test file), do the half notes in voice1 stay with the stems Up, as expected ? Ie: https://musescore.org/en/node/309188#comment-1019995
Test file: test voices rests.mscz

No they don't. And they shouldn't either IMHO.
Hiding the rest has the same result as deleting it.
If you want/need it, flip the stems manually.

Sadly. And I disagree on the rest. The previous behavior was preferable, by far: namely, an action in one voice (deleting/hiding a rest for example) must not, should not, strictly speaking have any effect on the direction of the note stems in the other voices. In guitar writing, and its multi-voice context, this is a permanent mess. It may seem trivial to toggle a note with the X shortcut, but when you have to do it systematically in many situations - and check that you haven't forgotten any (when this problem didn't exist before), it's just a boring regression. So, precisely, just to avoid: "If you want/need it, flip the stems manually."
Minor problem for you, even non-existent, major and boring problem for me in my daily practice.

Well, I disagree, hiding voice 2 should result in a layout as if voice 2 were not existent. At least as far as stem direction is concerned

Ok, let's forget it, you don't understand multi-voice writing for guitar obviously.

Indeed I don't. I do for Closed Score SATB though.
Maybe a staff property for this is in order (similar to the 'merge matching rests'), se we both can get what we need, via a template for example.
Feel free to file a Suggestion for that

@cadiz1 you might want to check again - it has not worked the way you describe for years. The change of mine that caused this is in 2.3.2 as well. The feature I implemented - making sure invisible content in other voices doesn't affect voice 1 unnecessarily - was buggy enough that it didn't work in some cases, including with rests, but it definitely worked exactly as expected for hidden notes.

Try entering four quarter notes in voice 1 (top line F, say), then four more in voice 2 (bottom space F), then mark all the quarter note noteheads in voice 2 invisible. The voice 1 stems will return down. This is by design and quite necessary behavior for many cases, such a when adding invisible notes for playback purposes. And in many of those cases, needing to use "X" to flip the stems is not an acceptable workaround, because if this is a transposing instrument, those stem directions might not be correct in both concert and transposed pitches. That was actually the main reason this feature was requested and implemented.

In any case, the change proposed by Jojo would actually fix this very case - because you are hiding noteheads only, but not stems. So this years-old bug will be fixed. Be happy, not sad :-). With Jojo's change, the only time voice 1 stems will revert to default is if voice 2 is completely empty - not just noteheads hidden, but stems, rests, and everything else. If anything in voice 2 is visible, the stems remain. Since your use case has you hiding noteheads only, you'll see only improvement, just like everyone else will.

But it is true that an invisible rest will not force a stem up. For most cases this is exactly as expected. It does mean there might be cases where you still need to manually flip a stem up if the only thing in voice 2 is an invisible rest, because again, this is what is desired in the majority of cases.

Fixed in branch master, commit 810a33c520

Fix #320517: Voice 2 note stems face wrong way when noteheads made invisible

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

Unfortunatly this seems to have caused a regression: a (visible) voice 1 is all up-stem in presence of an invisible voice 2! Only exception seems to be rests.

See https://github.com/musescore/MuseScore/pull/8967

Fixed in branch master, commit a72598b6c9

_Fix #320517: Voice 2 note stems face wrong way when noteheads made invisible

Follow up for #8012_

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