[Fingering Placement] Implement "Auto" VS Explicit "fingering above/below"
Fingering placement is automatically decided by the properties of the staff and the chord it's attached to, and the decision is the same as expected on most occasions, it's similar to articulation anchor. While articulation anchor setting in the inspector has "Auto/Above Stave/Below Stave/Above Chord/Below Chord", "Auto" as default, fingering placement only has "Above/Below", and the default depends on whether it's actually above or below.
Currently, fingering placement is a styled property, but because the default is not a constant, it leads to issues like #288372: S button beside "placement" property of fingering resets the property. The style of fingering placement cannot be customized, even if the user wants to. If "Auto" exists then it will always be the default, which is more logical then having the default depending on the circumstances, and therefore the cause of that issue is eliminated.
However, there's another voice suggesting explicit "fingering above" and "fingering below", so users can decide which one to use in the first place. Due to the fact that the automatic placement gives us almost exactly what the majority of users want already, is it really necessary to separated a single type of elements into two categories?
For those of you who want fingerings to be always above/below, this idea is probably most ideal. But this style of fingering placement isn't usual, though it's probably not as unusual as, say, putting all articulations above/below the staves/chords. So, how many of you are willing to layout the fingerings in this way? Would you really like to see fingering separated into two subtypes?
Ultimately, there is an idea which applies to all cases. "Guitar music is often written with the string numbers below the staff and finger numbers above", said @edrmiller, so what if we create a separate "Fingering" style page and make the placement of each subtype of fingerings a style setting, default to "Auto", but can be changed into "Above" or "Below"? And the same three choices for the placement property of a single fingering: "Auto", "Above" and "Below", the default depending on the style setting. This can fulfill the need of almost every user, but it's also the most complicated. So, if the most of you think a simple "Auto" or "fingering above/below" is just fine, it's best to follow the approved idea.
Comments
I will summarize the issue as follows:
Right now, the fingering default is neither above nor below - it's above sometimes., below other times., depending on use of voices and staves. So that's why there is no ability to set the style default. But we get that sometimes people might want to be able to force all fingerings below. OK, so what if there were simply a "fingering below" element on the palette you could add, that would always be added below? It would be as if you had changed the style default. You can actually have this right now - just add a fingering to your score, flip it below, then add it back to your palette. The only change we would actually need to make would be to preserve this placement in "fingering mode" (after hitting Space), which would be trivial I think.
Would that satisfy the use cases for which people are currently wanting "set as style" to work for fingering placement?
In reply to I will summarize the issue… by Marc Sabatella
If "fingering above&below" exist, does this mean the present fingering should be removed?
In reply to If "fingering above&below"… by Howard-C
Not at all! For the vast majority of use cases, the existing fingering elements, with automatic placement above or below based on voice & staff, is exactly correct. it's only a very small percentage of cases where anyone would ever need to consistently force fingerings to the "wrong" side. So only those users would have any reason to access the "fingering below" element. Meaning, I propsoe we don't even add it to the paltte, let those few users who need it add it themselves. The only thing I see us needing to do is make sure to honor the previous placement when creating a new element in "fingering mode". And this would be useful for other types of text as well. That would be done by forcing the placement at the bottom of ScoreView::textTab(), where we call cmdAddText(). We'd need to add two new parameters, probably, a bool "force" (defaults to false) and then a parameter to specify which way we are forcing it.
In reply to Not at all! For the vast… by Marc Sabatella
Well, I'm confused here: how do you add a customized thing into the palette? What is "fingering mode" exactly?
In reply to Well, I'm confused here: how… by Howard-C
Ctrl+Shift+drag is how you add elements from your score to a palette - see the Handbook for more information on palette customization (although I suspect it's at least partially out of date unless someone updated it for 3.3; no more need to create a workspace or make the palette editable).
"Fingering mode" is the usual way of entering multiple fingerings - while in edit mode on one fingering, press Space to instantly move to the next note. So you can enter fingerings by typing number, space, number, space, etc, just as easily as lyrics.
In reply to Ctrl+Shift+drag is how you… by Marc Sabatella
I still have some doubts regarding the details, I can play with the fingerings in MuseScore later. But adding fingering above/below doesn't really resolve that graphical issue, so maybe it's best to implement "Auto" AND add fingering above/below. After all they don't contradict each other.
If these two are both realized, should the "placement" property be styled anymore? I guess if I have enough time, I will work on "Auto" first. So, if there's a time gap between "Auto" and fingering above/below, would you still like to see the property styled? Because as long as it is styled, that S button will always be there, and the issue will presist unless even more work is done (like adding a
FingeringPlacementclass which hasAuto,AboveandBelow).In reply to I still have some doubts… by Howard-C
If it becomes possible to set as style for placement on fingering, I can't imagine any possible reaosn to add hardcoded fingerings to the palette. I already thin it's unnecessary, since as I said the user can do it themselves But honoring placement in "fingering mode" makes sense no matter what, and is simple.
As for the styling of placement, well certainly, why wouldn't we? That's the whole pint of adding "auto" - so it becomes possible to meaningfully set as style. The goal isn't to get rid of "S" button - it's to make it actually work.
But, it's an extremely minor glitch compared to many other far more important things that would be easier to fix.
In reply to If it becomes possible to… by Marc Sabatella
Yes, the graphical glitch is minor, but not able to set placement as style is a non-trivial problem. Sounds like you agree with
FingeringPlacement, very well, I will try to encode that. If it's successful then we don't have to worry about fingering above/below anymore.In reply to Yes, the graphical glitch is… by Howard-C
What do you mean by "non-trivial problem"? Difficult to fix, yes, but not very important to fix. The default is correct 99% of the time, It's going to be very rare someone would actually need to alter the default. And for those rare cases, you can customize your palette. So I still say, just enhance fingering mode to preserve the placement, and there will be literally no real world use remaining that still would make anyone thing they needed to set as style. Certainly the use case shown in that original issue doesn't require set as style, it's solved completely with a custom palette and the simple fingering mode enhancement.
But for the record, no, I don't think a new fingeringPlacement class is a good solution. I think someday the regular placement property should support an auto value. Because there may well be other element types that could benefit down the road.
In reply to What do you mean by "non… by Marc Sabatella
There can of course be an "Auto" value for the property, but not for the style. "Placement" style doesn't have "Auto" now.
And, you meant you still support letting users to add explicit fingerings themselves rather than having a score style really in play or fingering above/below added to the palette?
In reply to There can of course be an … by Howard-C
I am not understanding the distinction you are making here. The whole point of a styled property is that the values of the property are the values of the style. So the "real" fix (the "overkill" fix, I'd say) is to add "Auto" as a value for the property, and thus, for the corresponding style value. You can't have one without the other.
In reply to I am not understanding the… by Marc Sabatella
But "Auto" simply isn't a usable value for a style setting yet.
In reply to There can of course be an … by Howard-C
I don't understand the last sentence "you still support letting users to add explicit fingerings themselves rather than having a score style really in play or fingering above/below added to the palette". Once again, I am saying that once a user realizes he can customize his palette to add the "string number below" - it literally takes five seconds - his problem is over, and he stops caring about needing set as style. He can henceforth just add the new palette element instead of using the old.
In reply to I don't understand the last… by Marc Sabatella
OK, then I don't have to say that as a question anymore.
You still support letting users to add explicit fingerings themselves rather than having a score style really in play or fingering above/below added to the palette.
Is it the fact now?
The difference is that, these are completely different operations for users. Creating a custom element and adding to palette is one; attaching one of the existing fingerings, changing the property and setting it as style is another; attaching a new "fingering above/below" is another. You're saying you prefer the first one. Is it not true?
In reply to OK, then I don't have to say… by Howard-C
I'm no longer talking about a new fingering above/below, once I realized how trivial it was for the user to add them himself. So there are only two solutions being discussed: user customizing the palette to have a fingering fixed to below, or adding an "auto" value to the property & style so that set as style can be made to work.
I'm saying that creating a custom element is possible right now, and enhancing fingering mode to preserve placement takes less time than we've spent writing these posts. It solves exactly the same (uncommon) user problem that a working "set as style" button does, and it can be completely implemented and tested in minutes, with absolutely zero impact on compatibility, zero risk of breaking anything else.
Whereas adding an "auto" value to Placement has implications through the code, would require probably 100 times more effort to implement, would require extensive testing, and would almost certainly break compatibility - a score that relied on this would not load correctly in older versions.
So yes, I prefer the first solution to the problem over the second for the short term. Then someday, after solving the many much more important problems, we can worry about supporting "Auto" as a value for placement, perhaps for MuseScore 4 should that ever become a thing.
In reply to I'm no longer talking about… by Marc Sabatella
I don't see why there're compatibility issues, the tag is and always will be
<placement>, why wouldn't a score reling on "Auto" load correctly in older versions?In reply to I don't see why there're… by Howard-C
I have no idea what would happen if an older version read a placement tag with a value of auto. Maybe it works, maybe it doesn't. Probably it's possible to add yet another level of complexity and prevent the compatibility problem through some additional hack, but that makes it that much harder to implement, that much harder to test.
I'm not saying it can't be done, I'm saying it's a ton more work, a ton more risk, than the much simpler solution to the problem at hand. So again, you asked, I answered: to me the simpler solution is better short term.
In reply to I have no idea what would… by Marc Sabatella
It doesn't need to be that complicated! If there's no placement tag, then the position is auto (this is true for current version too), and if there is, then it decides the position. The placement tag itself doesn't have to include "a value of auto", the programme decides whether it's auto by seeing whether it exists! I believe the commit you linked to in that PR already guarantees this: if the position isn't styled, there's no placement tag. The behaviour is exactly the same as that of articulations.
In reply to It doesn't need to be that… by Howard-C
If auto is a valid value, it should be in the dropdown for the user to select, and in fact should be the default value for fingering. Because it's the default, it won't be written normally. But if the user explicitly changes to something else, that makes the property unstyled, and if he changes it back to auto, it remains unstyled and thus gets written.
Articulations don't use Placement, they use Direction, and Direction does have an auto settings already.
As I said, I'm sure it's solvable, but it's going to be far more complex and risky.
In reply to If auto is a valid value, it… by Marc Sabatella
Articulation direction isn't a styled property. And in fact, no, those properties changed back to "Auto" aren't written anymore, articulation direction for example. So there shouldn't be an "Auto" property tag, if it's auto, it isn't written.
In reply to Articulation direction is… by Howard-C
True, articulation direction not currently styled. All the more reason it isn’t a good analogy. But - for properties that are styled, changing them from the default makes them unstyled, and then they are written, even if you later change them back. Only “Reset” makes them styled again.
In reply to True, articulation direction… by Marc Sabatella
Does merely flip twice really change the property to "Auto" and record so in the file? Present fingerings don't record "Auto" as well, if one is flipped twice the placement tag is deleted after being created. Don't know if this will be different if the style and property become properly linked.
In reply to Does merely flip twice… by Howard-C
Well, there is no Auto, so flipping it will never set it to that. But if Auto is ever added, then a user can manually set it to that.
Right now if the default is above, we don't actually write the tag if you flip it down then back up. That's true for other elements (eg, staff text) as well. It's actually a bug, it causes the property to lose its unstyled flag on save/reload. Anything you do to make an element unstyled is supposed to be a way of locking it - making it immune to future style changes. So this is broken right now.
For example, take a staff text. Flip it below, then above again. Now add another staff text somewhere else, flip it down, then hit set as style. Note the first text remains up, because it is now unstyled (which you can tell because the reset button remains active).
Now save and reload, The reset button is now greyed out for that text, showing the text has become styled again. Add another text somewhere else, flip it down, hit set as style, and now the first text does follow, even though it shouldn't, because it is styled again. That happened because we failed to write the tag for the unstyled property. This directly contradicts the comment at the top of ScoreElement::writeProperty(), that says "unstyled properties are always written regardless of value".
It seems this was probably broken here: https://github.com/musescore/MuseScore/commit/752328610ef550f0d3ed9e4f1…
The test was previously for nostyle specifically, so we'd compare against the default only in that case and always write for unstyled. Now we compare against default for both unstyled and nostyle. I expect that changing it back will break the issue that this change was designed to fix, so it's another case of things being complex and inconsistent but we need to support it somehow.
Bottom line, this stuff is complex and fragile and messing with it comes at a price. Which is why I keep saying, if we can solve the problem without messing with this, that is preferable.
In reply to Well, there is no Auto, so… by Marc Sabatella
Now I understand. Yes, we'd better postpone that. 😊
In reply to I'm no longer talking about… by Marc Sabatella
And if I understand this correctly, "enhancing fingering mode to preserve placement" achieves: if on a staff which is supposed to have fingerings above, you enter fingering mode from a fingering below, and press Space, the following fingerings will all be below.
In reply to And if I understand this… by Howard-C
Correct. It's a good enhancement, useful not just for fingering.
In reply to Correct. It's a good… by Marc Sabatella
So this improvement should be made to general staff text?
In reply to Correct. It's a good… by Marc Sabatella
And you explained earlier:
> That would be done by forcing the placement at the bottom of ScoreView::textTab(), where we call cmdAddText(). We'd need to add two new parameters, probably, a bool "force" (defaults to false) and then a parameter to specify which way we are forcing it.
What's the criteria for that
forceto betrue?In reply to And you explained earlier: >… by Howard-C
I would say, if the original element had a placement that was not styled, this means there is either no corresponding style setting, or the user had explicitly customized it. Either way, these seem like the case where we should force the placement to be the same. Otherwise, if the property on the original was styled, we should let cmdAddText just add it and it will pick up the style default, which is what one normally wants.
In reply to I would say, if the original… by Marc Sabatella
Makes sense. Thanks!
In reply to I would say, if the original… by Marc Sabatella
PR created at https://github.com/musescore/MuseScore/pull/5475. Reviews are welcome!
Hi @Marc Sabatella!
I have been thinking about the ideal situation of "styled" things you mentioned, and I'm not comfortable with it.
The core of your explanation is, going from "styled" to "unstyled" is a one way ticket: you alter something, that thing becomes "unstyled", and it cannot return to "styled" again, even if it returns to the default value.
My proposal is: if it returns to the default value, it becomes "styled" again, unless the user presses a button, which can be called "F", meaning "Fix property", so even a change of the default value cannot alter it.
Reason: if I want something to be locked on the default value, I wouldn't ever think of the operation of "flip and flip back". Instead, I would look for some other button to do that.
"Flip and flip back" is most performed when the user hesitates. Flip? No, that doesn't look good, better flip it back. In this case, they probably want to keep the element consistent with other elements which have the default properties. If they suddenly want to change the default, re-layoutting the overall appearance, they would want all elements which have the default values fit into a new default. If several of these have become "unstyled" without being noticed, then the score will look like a mess.
If there is an "F" button, all become clear. If users want to "unstyle" something without changing to a different value, press "F". Then "flip and flip back" can have less ambiguity.
In reply to Hi @Marc Sabatella! I have… by Howard-C
No, you are misunderstanding. It's not a one-way street at all. A *reset * of the property - either using the reset button in the Inspector, or the reset command (Ctrl+R or via menu) returns it to styled. Flip & flip back locks, has worked well that way for years, many people rely on this behavior. I don't see the need to complicate things further with yet more commands, but as long as it doesn't clutter up the interface or steal a valuable default keyboard shortcut (eg, user needs to customize it himself), it doesn't hurt I guess to have an explicit "force unstyled" command. But it's important not to break the expectations of existing users and scores with respect to ordinary property changes.
In reply to No, you are misunderstanding… by Marc Sabatella
Is there evidence to prove that many users rely on "flip and flip back"? If there is, then I'm OK with the current design.
In reply to Is there evidence to prove… by Howard-C
I don't have any specific evidence, but it's been this way for many years, and the behavior is pretty well known, so I'd be surprised if people didn't rely on it. It's not unlike the situation with stem direction, where flipping it twice doesn't return it to Auto, it locks it. This is deliberate, known, and by now expected behavior.
In any case, it was designed this way for good reasons. Redesigning long-established fundamental behaviors like this is not something should undertaken except when absolutely necessary to address some sort of critical flaw that cannot be addressed any other way.
In reply to I don't have any specific… by Marc Sabatella
Fair enough.