Hidden rests in V2 etc. are drawn over the top of notes in V1

• Jun 19, 2021 - 22:43
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.


Comments

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 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).

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.

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.

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

version2.jpg

vs. (currently)

version3.jpg

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!

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 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 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 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 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 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.

In reply to 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).

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 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 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.

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).

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 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

"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.

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.

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.

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.