Hidden rests in V2 etc. are drawn over the top of notes in V1
Reported version
3.6
Type
Ergonomical (UX)
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
1) Add a few notes in V1 around the middle of the staff
2) Now add a few notes and rests in V2 in the same measure
3) Note that the V2 rests are positioned to avoid clashing with the V1 notes
4) Select the V2 rests and hide them
5) Note that they're now drawn over the top of the V1 notes
https://media.discordapp.net/attachments/818848561047273544/85592395906…
I understand as they're invisible there's technically no need for the automatic collision avoidance logic to kick in, but it does make the score look quite messy while you're working on it, and harder to interact with individual elements. At the least I'd expect them to be drawn "under" the V1 notes.
Fix version
4.0.0
Comments
You can turn off the display of invisible items from the view menu for a wysiswy really g view.
In reply to You can turn off the display… by SteveBlower
Why would I want to do that? I still want to be able to see them/interact with them if necessary. Not to the mention the fact that option is global and hides all invisible items completely which I can't imagine ever wanting except when looking at the print preview.
This is by design. And got added befor the staff property of "combine matching rests"
In reply to This is by design. And got… by Jojo-Schmitz
Um, what possible reason is there for a design that says hidden rests should be drawn over the top of non-hidden notes?
They just fall to their default position, as if no other voices where there. And don't clutter the view (in the situations where they fall on top of one another)
In reply to They just fall to their… by Jojo-Schmitz
I'd like to say I understand that explanation, but sadly it makes no sense to me. Are you saying that previously if you had hidden rests in multiple voices people were complaining that you didn't need to see all of them in different positions? And that somehow drawing hidden objects under regular ones was making the score harder to read? Do you have an example? I'm really quite at a loss as to any good reason for the current behaviour except the fact that the devs felt it was a waste of CPU cycles to adjust the position of hidden elements in the collision detection algorithm (and as I've said before, MuseScore's collision detection is generally very very good - which is why it's all the more surprising when it gets it wrong).
It has got nothing to do with collision avoidance, got introduced long before that.
Then how can it possibly be that it's by design that hidden rests aren't positioned to avoid colliding with non-hidden ones? Anyway, whatever design decision might have made sense that long ago pretty clearly doesn't any longer.
Well. For my part, I use the program for composing, arragning, printing and publish music. For this I need the best possible layout for the music I want people to see, not hidden objects. If MS did place hidden objects so they did not collide with other items, the printed and published music will see a bit strange out (or sometimes very strange if there are many hidden objects). Simply put, what I want to see will be moved around and have empty spaces because of things I do not want to see (and by that I mean hidden items)
Have a nice day
The point of hidden voice 2 rests is that corresponding visible voice 1 rests move donw as if there were no voice 2 rest. This feature is still needed, at least for backwards compatibilty.
Where those hidden rests are "shown" is not really important though.
In reply to The point of hidden voice 2… by Jojo-Schmitz
But that's the other way around! I'm not suggesting for moment that visible elements should be moved to avoid colliding with invisible ones.
In reply to Well. For my part, I use the… by larshenrikoern
Can you explain? I'm only suggesting that hidden objects should be moved to avoid colliding with regular ones, not that non-hidden objects should be moved at all. I.e. the printed output should look exactly the same.
Why should hidden elements avoid collisions, they are not visibla affter all? I see no use for that.
I think that is a huge thing to ask for. The layout of music and notes is the most complicated thing of all types of layout in the whole world. And it is already far from .optimal in MS. But big improvements will happen in the next years.
In reply to I think that is a huge thing… by larshenrikoern
Actually it's a very simple change, just removing a single test whether elements are visible when determining if their position should be adjusted. I've already been working quite extensively on the MU4 codebase.
In reply to Why should hidden elements… by Jojo-Schmitz
Look at the image I linked to. The visible elements are significantly affected in appearance and clickability. I'm actually really struggling to understand why this is even contentious.
The behavior was different in version 2 and in first versions 3 (see image below with 2.3.2).
The change occured for the version 3.5 (April 2020) , and, after checking, I am pretty sure this is the same cause and consequence described in this issue: #320517: Voice 2 note stems face wrong way when noteheads made invisible
vs. (currently)
EDIT: And I also agree, that I do not like this behavior. It produces collisions that are unpleasant and visually improper. And as you can also see, the beams switch (second beat) down in a totally unexpected and tedious way - I have explained this several times!
So a 3.5 regression then?
As long it is not going to make the print result looking worse. It is not acceptable if it will make prints and pdf's from MS look worse. In the last couple of versions it has actually improved a bit. In the above example it is not a big problem, but in cases with 3-4 voices and a lot of hidden items it might look horrible on print.
In reply to The behavior was different… by cadiz1
The beaming is probably as expected though - if there is nothing visible in V2 for the whole duration of the beamed-together notes then I wouldn't expect the beam direction to adjust - but that is a good point, that it would be hard to avoid collisions with invisible elements in that case.
BTW I found the problem - the function that determines whether any beat of a measure has multiple voices just checks whether there's elements visible in more than one voice. So if you add notes in voice 3 (even if they're way above the top of the stave, so have nothing to do with collision avoidance), the hidden voice 2 rests move down as expected. Easy to fix, just need to determine what else it might impact.
But as part of that I noticed that rests in V2-4 are shifted down even if there are no visible elements in V1. Is that expected?
The simplest fix actually fixes that too, but I'm worried that is by design for some reason...
This is not just about beaming, but about spacing of all visible elements. The big and very advanced art of music engraving. And in that there are almost no room for hidden objects. They will make things look strange when they are not there. My goal is to make the engraving as perfect as possible. Because then music is so much easier to read :-)
In reply to But as part that I noticed… by Dylan Nicholson1
In fact I take that back - if the intention is that visible rests in V2-4 should always be shifted regardless of whether there's any visible V1 elements, then arguably we should do the same for invisible rests.
It's pretty rare you'd have a beat with all invisible rests in all voices, which is the only thing that won't look quite right now.
In reply to This is not just about… by larshenrikoern
Again, I'm not proposing any change that would affect the placement or appearance of visible elements at all.
Just invisible ones.
As it happens the logic for how to place rests when there are multiple voices is almost absurdly simple. It's a tiny change to ensure ALL rests in V2-V4 get placed to avoid colliding with V1 notes/rests (vs only visible ones, as it is now) - the only slight issue I have is when notes/rests in all voices are hidden, but that's very much an edge case.
In reply to In fact I take that back -… by Dylan Nicholson1
The current general collision avoidance algorithms for item X can have as consequence to move items Y, Z, ... e.g. moving staves further to make room.
So I agree with the O.P. that avoiding collisions while drawing invisible items would be a good thing, but I disagree when he says it is "simple". It would need a complete new block of code moving invisible items but without interfering in any way with visible ones.
In reply to Again, I'm not proposing any… by Dylan Nicholson1
It's definitely an improvement, but there are still a few cases where the invisible V2-4 rest collides slightly with the V1 element, especially if its a note with down stem, or a 1/4 note rest - not sure if it's worth trying to fix that, except it is technically a "regression" (currently they're drawn over the top of each other which isn't really much better!). Ideally an invisible rest in V1 should be offset too if there are any v2-v4 rests at the same position (visible or otherwise), but that's a slightly riskier fix. Anyway I'll put up a PR tomorrow.
My main concern is how it will do to what is described in thes thread: https://musescore.org/en/node/299741
In reply to The current general… by frfancha
All I did is change the 2nd line of Rest::computeLineOffset to
bool offsetVoices = s && measure() && (voice() > 0 || measure()->hasVoices(staffIdx(), tick(), actualTicks()));I.e. if it's a rest in v2-4, then always offset it. If it's v1, only offset if there are visible v2-v4 elements at the same position (which is what "hasVoices" determines).
In reply to My main concern is how it… by larshenrikoern
What does that have to do with invisible rests? Again, the ONLY thing I'm changing is how invisible rests are placed, nothing else.
For the record, mostly invisible objects do not revert to non-autoplaced defaults. Eg, add a note far above the staff, add staff text, make it invisible - the text remains above the note, doesn't fall down to its default position closer to the staff. This is deliberate, and the behavior predates the new collision avoid for rests. I don't see why that should have been implemented differently.
On the other hand, ultimately I can't see that matters much how those invisible rests are placed, but how they affect visible ones is important. There is a bug in 3.6 involving rhythmic slash notation where that offsetVoices does the wrong thing for rests in voice 3 if voice 1 is slashes (the rests should be offset). I believe it's fixed for master. So I'd be fine with seeing the placement invisible rests changed so long as it doesn't change anything else.
Because all elements of the score is influencing each other in the layout. There is not such a thing as "correctly placed invisible rests" do not affect layout and spacing. It does, because when you remove them the layout and spacing changes. So the current situation where they are not influencing visible elements is much to be preferred from my view.
In reply to For the record, mostly… by Marc Sabatella
But that's different - and surprising - I would expect that if text is autoplaced further from the staff because of a note, then if the note (including its stem and flag) are made invisible, it should revert. In general I wouldn't expect invisible items to affect the placement of visible ones.
At any rate that's completely unrelated to how rests are offset if there are multiple voices.
In reply to Because all elements of the… by larshenrikoern
Ah, well that's a different bug again - it seems the mere presence of invisible rests does in fact affect the horizontal layout (i.e. if you fill a measure with invisible 16th note rests, it will be wider than a measure without them).
But the change I'm proposing ONLY affects the vertical offset of invisible rests, nothing else. It has absolutely no impact on how the position or spacing of visible elements is calculated.
Unless there's a way of attaching text or something else to an invisible rest in V2/3/4? I haven't found any type of element etc. that moves up or down depending on how an invisible rest is placed so far. If there was, I'd consider that a separate bug.
In reply to Ah, well that's a different… by Dylan Nicholson1
Ah - fermatas move up and down when attached to rests, but thankfully confirmed that doesn't happen when the rest is invisible. Interestingly if you manually move the invisible rest horizontally, the fermata follows though, just not vertically.
You can attach lyrics to rests. Regardless of voice or visibility. Not sure whether that is a problem though
In reply to You can attach lyrics to… by Jojo-Schmitz
Just tested that too - weirdly when you move the rest around, the lyric does too, but when you drop the rest, the lyric reverts back to its default position. Doesn't happen when the rest is visible (the lyric correctly drops at the same relative position to the rest).
It would certainly be preferable. But is the code for hidden notes and spacing separated, or it is the same code and algorithms at work for both items. I doubt it is currently separated. It will be the same code. And if so then spacing and layout changes, making invisible items impacting in the final layout.
Multiple voices was just one example where it is obvious things easily goes wrong. But distances between stems, noteheads, barlines and everything else changes if just one element is added or changed. But if the code can be made in a way so this is not happening it is fine for me (and it can but a lot of work required to do so).
In reply to You can attach lyrics to… by Jojo-Schmitz
Jojo. Text on rests. It is a feature. Words to be said not sung. Invisible items are good for that
In reply to It would certainly be… by larshenrikoern
I'm still puzzled why you think it's a lot of work - it's literally a very slight modification to one line of code as described above. If it were a lot of work I'd agree it wouldn't be worthwhile.
I am not against the change per se. But it is important it is not introducing new or reintroduce bugs in the layout. And your own comments above tells me that it does introduce new bugs and spacing problems. And that is to me a very bad thing. The end result of my work with MS will be less beautiful. I am also using lilypond as well because of the beauty of the output. But that program is not very usefull for arranging and composing.
In reply to I am not against the change… by larshenrikoern
Which comments? As I explained repeatedly my change doesn't affect the layout/ spacing/ appearance of any visible elements at all - unless there's some element I don't know about whose position can be altered due to the vertical position of an invisible rest in v2-4, and if such behavior does exist I'd consider that a bug its own right.
Thank you for asking
As you can clearly see in Cadiz example above the stem directions are changing when there are invisible rests. And by that changing the non hidden notation to non standard. When things like that is happening there will be a lot other things going on. Spacing for instance is a very subtle art. Most people cant see such changes easily, but will magically read things a lot easier . Have you seen Tantacruls video about the new font. I think we need someone like him to look into this. I for instance do not have access to your changes and have the ability to test them out. Al lot of the postings the lilypond website is about such small changes. People there all have ocd. But the result is very good.
But I suggest you make a patch with the and then lets see what happens with it :-)
Have nice day
In reply to Thank you for asking As you… by larshenrikoern
The cadiz example shows that there was a change in musescore so that hidden rests/notes in v2-v4 no longer affect the stem direction of v1 notes.
It's completely unrelated to the change I'm proposing, which only changes the vertical offset of hidden rests in v2-4. Sorry to sound like a broken record.
"I would expect that if text is autoplaced further from the staff because of a note, then if the note (including its stem and flag) are made invisible, it should revert." - that's not what I meant, but I realize I used the word "it" in a context where it was ambiguous. What I wrote was:
"add a note far above the staff, add staff text, make it invisible - the text remains above the note, doesn't fall down to its default position closer to the staff"
The word "it" in the phrase "make it invisible" here refers to the text, not to the note. In other words. if a text is displaced above the staff because of a high note, and you make the text invisible, then the text remains displaced. This was the pretty much universal consensus when the autoplace feature was initially implemented and worked the other way at first. And it's consistent with what you are saying you'd like to see for rests too. So, I'm agreeing invisible rests should be displaced as well. That feature was implemented by someone else, years later, so it is an accident to me that it wasn't made made consistent with the behavior of other similar cases.
In reply to "I would expect that if text… by Marc Sabatella
This and your previous comments, sums up my concerns very clear. What I want to ensure, is that hidden objects in no way changes the placement and behavior of visible elements
In reply to "I would expect that if text… by Marc Sabatella
Ah ok - but it is true that staff text remains offset if the note that it's attached to is made invisible, which seems wrong to me.
Agreed, that seems wrong. Notes are tricky in that there are many components to them that are each individual elements (children of the Chord object) and hence no one visibility property, but still, each should be managed independently with respect to the skyline. Not sure why that isn't the case.
In reply to Agreed, that seems wrong. … by Marc Sabatella
Well I noticed in one place it checks if the note, its stem or its flag are visible - but I don't know how that works for notes that don't have stems or flags! Can't imagine why you'd want to change the visibility of a stem or flag separate to the note itself TBH.
Hiding stems or flags individually is a commonish-ish trick for creating the appearance of a whole note on a note that needs to be shorter for other reasons. Happens a bit when creating excerpts of scores and you want to show an incomplete final measure of the excerpt, and in other educational contexts as well.
In reply to Hiding stems or flags… by Marc Sabatella
But the shape of a whole note head is unique, you can't get it from hiding stems/flags?
Would have thought any scenario where you really did need it you could do it with multiple voices or even text.
BTW I've put up a PR for this that fixes half the problem in MU4 - ensuring that V2-4 rests remain in the "offset" position even when hidden.
But I still think hidden items should be logically be painted under visible items, and I've worked out a couple of ways to do this, it just depends what behaviour we want. I think the best compromise is that hidden items that are normally painted on top of staff lines have a z-order (stacking order) that's just above staff lines, but below that of other visible elements like accidentals/notes/rests etc. That means that the z-order for hidden items is upper-bounded only as high as the default z-order for staff-lines (essentially, hidden rests/notes are always painted on top of staff lines, but below everything else).
But if you manually modify the z/stacking order for any items you may still have situations where hidden items are painted over visible ones.
Fixed in branch master, commit 52f57a8ab8
[MU3] Fix #322347 - ensure hidden rests in V2-4 don't move back to default position
Automatically closed -- issue fixed for 2 weeks with no activity.