[MU4 Issue] Clefs auto-place error

[cgpqci]

Describe the bug
Auto-place error causes clefs to collide with other elements, as well as affect other elements' auto-place behavior.

To Reproduce

1. Create score as of liking
2. Insert a clef on a measure's whole rest (not the measure itself)
3. Insert then any key signature or time signature on the same rest.
4. See first error: Overlap occurs with time signatures and key signatures

6. Insert a note to the measure's first beat OR divide measure rest into smaller durations.
7. Select all inserted clefs and set auto-place off.
8. See second error: Overlap also occurs with notes and rests.
9. See third error: Different behavior whether auto-place is on or off. When clef auto-place is off, the notes/rests now also overlap with time signature/key signature (at least, except in first measure of system). In addition, the inserted clef in the first measure now respects first time signature but still observes second error.

Expected behavior
Auto-place behavior should be correct, and all elements mentioned above should be placed appropriately.

Platform information
OS: Windows 10 Version 2009, Arch.: x86_64, MuseScore version (64-bit): 4.0.0-223072007, revision: github-musescore-musescore-2c34155

[oktophonie]

Slightly tangential to this (but something that has bothered me about MuseScore for a long time, and relevant to how we go about fixing this problem): what is the purpose of this behaviour, where if one applies a clef to a bar rest or the first note/chord in a bar, the clef appears after (rather than before) the barline?

This strikes me as essentially incorrect notation, and it seems odd to me that to achieve the 'correct' result, you need to enter the clef in a different way (by applying it to the bar itself, not to the note/rest) than entering it anywhere else in the bar.

There may be historic reasons for the 'clef-after-barline' notation, or use cases I'm just not thinking of, but as it's non-standard it seems like the means of achieving it should be different. I've seen far too many examples of this 'wrong' notation being used in MuseScore scores, presumably inadvertently, but it's quite understandable why that happens.

[MarcSabatella]

Lots of people over the years have specifically said they need clef after the barline for whatever special purpose and are usually able to show examples from published scores that does this for some reason or other. So we definitely knew we wanted to support it - and to fix the many bugs that have kept cropping up around this (like them constantly getting converted to normal clefs after save and reload in various situations).

Since selecting any note other than the first note is how we do mid-measure clefs, it seemed logical and consistent to do the same thing for the first note as well. That is, selecting a note within a measure, gives you a clef that applies to that note. Selecting a full measure gives you a clef that applies to the full measure. Selecting the full measure is the way we expect people to add clefs, as well as key signatures and time signatures.

It would of course be possible to change the behavior on adding a clef after selecting the first note, but we'd still want some way to get the non-standard behavior, and it's kind of hard to think of what a more intuitive way might be to do that. On the other hand, the ability to choose which side of the barline a clef, key signature, or time signature goes on would be hugely beneficial for addressing the religious wars over where these should be positioned in the presence of repeats. So, some sort of property to choose position relative to barline - with an "auto" setting but also explicit before/after - could be interesting.

[oktophonie]

Key signatures and time signatures most commonly (yes, not always) appear at a barline, whereas clef changes can come anywhere. A clef change doesn't really 'apply to a measure', they just happen to come at the start of one sometimes. This is maybe also a symptom of the 'measure-based' thinking that is a conceptual misjudgement that plagues most notation software.

I maintain that the default position for a clef change that comes at the start of a bar should be before the barline. But I agree that a style setting (score-wide but that can be overridden on a per-clef basis) would be good, to enable putting it after the barline where that may be needed.

In any case, wherever the clef does come after the barline, for whatever reason, all the items should be arranged properly.

[MarcSabatella]

Oh, definitely I agree that the default should be before the barline. I was just explaining how things got the way they are - the assumption really has always been, normally clefs, key and time signatures are added to measures, not to notes. That's the default behavior when you drag unless you try really hard to hit a specific note. And originally drag & drop was the only way to use the palette.

[cbjeukendrup]

@Tantacrul @oktophonie Is this a patch release 2 candidate? (just came up in the .org forum again)

[Tantacrul]

I'll leave that to @oktophonie and @RomanPudashkin. I have no objection.

[bkunda]

🟢 Re-tested in 4.0.2. on macOS. Remains FIXED.