Hidden notes and rests not displacing other voice
I wonder if this can be further refined.
If all elements of a note (head, flag, stem, beam) are not visible and don't overlap the values of another voice, the visible elements shouldn't be displaced. This would be useful for lyrics that aren't expressed to a particular rhythm.
Desired result: (Taken from 1.3)
Actual result: (Taken from 2.0 Nightly Build 1634901)
(The top image of each result is in MuseScore, whilst the bottom is an exported PNG.)
Using Mac 10.7.5.
Comments
I do wonder about the difficulty of accessing obscured rests (something expressed by others, I believe).
I'm not sure, but would moving the invisible ones vertically work? If more than two voices are in use, could it produce problems elsewhere?
I see at one time I submitted a related feature request: #9355: invisible rests affect stems in other voices, and I continue to think about this from time to time.
Trouble is it is not necessarily clear when this would be OK and when it might not be. There might be any number of use cases where even though something is hidden, you might still want rests offset and stems flipped in other voices. And detecting which cases are which based on anything beyond a very simplistic model would seem to require "parsing" the entire measure just to lay out a single rest. At least, that's my gut feel.
But there is a simplistic and quite implementable model that I think *could* be useful: the case where voices 2 & up are entirely empty except for invisible elements. We already have a function that goes through a measure checking to see if a measure uses multiple voices. Right now, it says "yes" if there exists anything in any voice other than 1. If I changed it to ignore invisible elements - thus only saying "yes" if there exists a *visible* element in a voice other than 1, I *think* we'd like the behavior overall. Rests would not be offset, stems would not be flipped, unless there are multiple *visible* voices to trigger this.
The case that brought this to my mind was adding an invisible note to suppress a staff from being hidden, but it would also address the issue I mention above as well as your use case here. BTW, I would say your "desired result" is still not good - the stems are flipped up unnecessarily. My change would actually fix that as well, as per #9355: invisible rests affect stems in other voices.
In reply to I see at one time I submitted by Marc Sabatella
Good point about the stem direction!
I was going to reserve this for another discussion, but since you mention it: With regards to layout for invisible elements, sometimes you would want it to be taken into account (e.g. if used as a placeholder), but for other cases, it is a hinderance. Maybe there can be a flag to control this?
In reply to I see at one time I submitted by Marc Sabatella
Regarding my suggestion: turns out it is pretty easy to make this work for invisible rests, not so easy for invisible "notes", because as you may know, there is a distinction between "chords" and "notes" within MuseScore that is no always what you might think. We couldstand to look at this too, though - not overall representation of chords versus notes, of course, but how visiblity works for notes. it's always been a bit of a drag that clicking a note and marking it invisible only affects the note, not the chord - so you have to get the stem separately (or selected it along with the note in the first place).
I might also suggest that while the Inspector could still retain its behavior of treating this stuff literally, we could special case the "V" command when applied to a note and have it automatically apply to the whole chord.
Regaridng ignoring layout for invisible elements - layout is a huge subject, as is the question of what it might mean to "ignore" it fr some given element. Whatever it is you are thinking of this meaning, chances are, it doesn't really make sense inplementation-wise. But feel free to explain what you do mean :-)
In reply to Regarding my suggestion: by Marc Sabatella
Turns out pecial-casing "V" for notes is actually trickier - what about multi-note chords, do we also want to hide arpeggios, beams, etc.
A simpler solution is to consider a voice non-empty if it has any visible rests or *notes*, even though this means a vocie might be considered empty if all of it's *notes* are hidden but the stems or beams or whatever are left visible. For one thing, why would anyone do that? For another, so what if it means the voice would be considered empty? Worst case you have to offset rests or flip stems in voice 1 manually. But there is at least some chance that whatever your reason for hiding all voice 2 notes but leaving stems or beams visible might happen to be, you actually want the voice 1 rests and stems to act as if voice 2 was truly empty.
So my current algorithm is - if voice 2 & above contain only invisible rests and notes (even though stems or other chord parts might be visible), then don't consider this measure to be multi-voice, and therefore don't offsets rests or flip stems. Seems to be working well enough for me so far.
I'll wait to see if others have further comments before doing more testing and submitting a PR.
In reply to Turns out pecial-casing "V" by Marc Sabatella
Here is a PR that implements what I describe: https://github.com/musescore/MuseScore/pull/1692
In reply to Here is a PR that implements by Marc Sabatella
PR has been merged. Please help test. The function that checks to see if a measure has multiple voices is only called "as needed" - when something changes that could possibly change the multiple-voice state of the measure. Since toggling visibility can now do this as well, I had to add new calls to the multiple-voice-checking function to be sure to change the state at the right times, and it's possible I missed some case. So be on the lookout for cases where you think the measure should have been considered mulit-voice but isn't or vice versa, and most importantly, *try to ascertain what the last action you performed on that measure was*. merely posting a score won't really help - most likely, the problem will have fixed itself on the save/reload anyhow. I need to know if there are any specific actions that should result in re-evaluation of the multiple-voice state of the measure but are not.