String numbers: allow positioning on the staff
Reported version
3.x-dev
Priority
P1 - High
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.6623, revision: 82f27b7
String numbers are positioned ON the staff (as well as above and below it) in published works. Could this be made possible in MuseScore, even with autoplacement ON?
S. Tennant, Pumping Nylon, p. 61 (Alfred Pub. Co., 1995):
Dowland, R, 6 Pieces from a Varietie of Lute Lessons (British & Continental, 1970):
Das Grieg Book (Musik Verlag Hans Sikorski, 1960):
Comments
I agree it sounds like a good idea. As I think through how this might be implemented, I'm seeing a few options, probably none of them completely ideal, but hopefully better than what we have.
Without going into too much detail right now, the biggest questions in implementing this are,
1) what should the default position be
2) what do we want to happen if there are multiple string numbers (eg, for a chord)
3) do we want collision avoidance with other notes once you have moved the string number onto the staff?
4) would we want two different string number types to get two different behaviors (so two sets of string numbers on the palette, or you can change text style to switch between the types)
I assume the answers everyone wants would be, 1) same as current, 2) same as current, 3) of course, and 4) no, we just want to be able to move them onto the staff. But I'm not seeing a way to do all of that. What I see as the best option is sacrificing 2) to get everything else. That is, if you enter multiple string numbers for a chord, they wouldn't stack like they do now, you'd have to resolve those collisions manually just as you sometimes might between LH fingerings for notes a second apart. The default position might turn out to be slightly different than current but similar. This much is quite simple. FWIW, it could also be done for RH fingerings, but here I suspect giving up the stacking would be harder to accept.
An interesting additional possibility if you didn't want to sacrifice the stacking would be to make that much only dependent on the autoplace setting. That is, with autoplace enabled, you get current behavior; with it disabled, you can move it onto the staff and yet it still affects spacing as I assume you would want. And if my PR to allow autoplace to be disabled more easily gets merged, this might seem like a decent option. But this is a bit of a "hack", I'm not really that happy with it.
There are other possibilities too, like saying "yes" to 4), so we have the option of string numbers that work like they do currently or ones that work more like RH fingerings do currently (stacked above the chord normally, but tucked in close to the notes under certain conditions we would need to identify).
Anyhow, I welcome further discussion!
Sorry, too many things, too complex/technical, your language (for me). Here, the only thing I need is to be able to move easily (ie without having to fight the program) a string number onto the staff. That's all. And it's not a fundamental priority (there are more important topics). I trust you to find the best way. This can be Alt + arrows Up/Down (alternatively Alt/mouse), if this is the way that will be chosen to disable automatic placement in your PR.
Sorry for the confusion, let me try to be clearer.
I can easily make it so you can move string numbers onto the staff, if you are willing to accept that if try entering multiple string numbers on the same chord, they won't stack. So I can give you this:
if you can live with this:
If that is acceptable, this is easy. If not, then we need to find other answers.
Also: my previous PR to disable automatic placement will hopefully be merged, and then Alt+drag will work, but it isn't really ideal here, because you don't really want it completely disabled. You would still want the string number to avoid other notes on the staff. In other words, you would want the string number to act more like LH fingerings.
"In other words, you would want the string number to act more like LH fingerings."
That's it. Expected, and sufficient (in my opinion).
Edit: But still with the ability to switch Above / Below of course.
I think I'm going to make you happy :-). I have figured out a way to get this to work exactly how one would want. By default, both string number and RH fingering will stack above or below the chords exactly as they currently do. When you begin moving one, it will allow collisions with the skyline, meaning you can move it on staff and yet will still affect spacing the same way LH fingering does. And you can still flip anything above or below the staff as well. At no time is autoplace disabled, although of course, if you want to, you can still can (and then spacing won't be affected by the fingering.
In reply to I think I'm going to make… by Marc Sabatella
The animation sounds good. Thanks.
Alternatively, instead of the mouse, I guess we can use arrows up/down to move these elements onto the staff?
Absolutely. A little more testing then I'll submit a PR.
Another question:
Right now, the string number "offset" style setting is -2sp. This makes string numbers always be 2sp above the top note of the chord. But is that really what we want? Does it make more sense to treat string numbers more like how we treat other text, with the offset meaning, place it at least this high above the staff, only moving it higher if needed to avoid collisions if there are notes above the staff?
Or, maybe, we should keep things as they are but change the offset to be less? They just seem awfully high to me.
In other words, which is better, the left (how we do it now), the middle (like we do for staff text), or the right (what we do now but with only -1sp as the offset)?
"Or, maybe, we should keep things as they are but change the offset to be less? They just seem awfully high to me."
Indeed, without any reason, -2sp is really too high.
-1sp as offset sounds better/good (and as on the third measure on your last attached pic)
In reply to Another question: Right now… by Marc Sabatella
Third measure is by far the best result for me.
But I would combine measure 2 and 3 behaviour.
OK, thanks for the feedback.
(EDITED)
The one snag I was running into is compatibility - if you made manual adjustments to your string numbers or RH fingerings in 3.0, I was having a hard time making them the same in 3.1 with my changes. But I think I have that under control now.
A -1 y-offset still leave the string numbers too high in the attached example score. A zero offset gives the minimum symbol-to-note distance. And this bug needs to be fixed at the same time: #285811: Fingering: adjusting position also moves other fingering on same note.
Do others agree that closer still is better? As part of #278999: Need option to completely disable Auto Placement, I am introducing a new style setting to control the minimum distance from note to fingering, like the "autoplace min distance" settings we already for staff text etc. I could set the offset for string number to 0, and then the autoplace min distance for fingering would control the distance, making it the same as for RH fingering (and piano fingering).
I have a PR for this as https://github.com/musescore/MuseScore/pull/4982. It's actually way more than just string numbers, as you can see here:
No use of Alt+drag or other disabling of autoplace was used - it's all just normal drag, and the same results are possible with cursor control keys. Basically, with this change, elements can be freely moved without disabling automatic placement, so other elements continue to avoid them.
I'm hoping that the code changes are considered acceptable and that it is merged for 3.1. It's really quite an exciting development to me.
I would very much like to see this get some real world testing sooner rather than later. Here is a link to a build that includes this change:
https://ci.appveyor.com/api/buildjobs/eyy0050symhpwrg2/artifacts/MuseSc…
Great work Marc, congratulations!
I started testing it : a really improved workflow (and without the nervousness generated by the previous behavior!)
It seems that you have managed to hit a big blow: reconcile the comfort of automatic placement, for those who need it for their practice, and the facility for others users who also want to be able to move where they want without having to fight against the program (and go every time in the Inspector, which was a real plague, in my opinion).
Moreover, there is no opposition, contradiction between the two practices. Only complementary, at different times or with different style scores. Anyway: Impressive progress, and I'm afraid now there's no way back!
While I tested, I noticed some inconsistencies, or oblivions, or maybe it's intended like that, I don't know (it's about the command "X", which was added a while ago I know it)
For example, in the Text palette: "Staff Text" and "Expression" can be toggled Above/Below with X key, but not Rehearsal Marks, "Swing", "Change Instrument" (I know you can do it via the Inspector)
Also, moving hairpins works with the mouse, but not with the direction arrows: or rather it works if you have previously modified the offset in the Inspector.
But these are minor things compared to the progress and ease of use provided by this commit.
Thanks for the feedback! FYI, this started as one of those projects where I thought I could solve a big problem in 20 lines of code in one afternoon, and in fact, I had it working that way at first. But it had unintended compatibility issues, so I needed an alternate solution, which ended up taking a week of pretty intense work to develop. Luckily I had the simple 20-line version to convince me it was possible and worth the effort!
BTW, regarding the "X" command - my PR actually includes a very deliberate change to preserve to distance from staff when flipping an element. So if you've moved an element further from the staff than the default, or closer to it, then you should get the same distance to staff upon flipping. But I didn't change anything else about it. I think there is a separate PR out there to handle the missing element types.
Moving hairpins with the keyboard should work if you first double-click and then select the middle handle (pressing Tab will do that). Not, however, if you just click on them. This is not a change from the current behavior. And this is true not just for hairpins but all lines. At least, that's how it is supposed to be.
"Luckily I had the simple 20-line version to convince me it was possible and worth the effort!"
-;)
"Moving hairpins with the keyboard should work if you first double-click and then select the middle handle (pressing Tab will do that). Not, however, if you just click on them. This is not a change from the current behavior. And this is true not just for hairpins but all lines."
Of course. I was testing a little bit of everything and anything without really thinking! :( Sorry.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.6760, revision: b5b0e52
Open the attached 2.x score and take the reset. The barre line in measure 3 is now sitting on the staff, rather than above the notes:
![barre_lines_ms3.png]( "barre_lines_ms3.png")
![barre_lines_ms2.png]( "barre_lines_ms2.png")
Should look like:
Confirmed, good catch! I think I see why this is happening, it has do to with the bad default offset of these lines in general (as per #287484: Lines ignoring Placement and/or Offset style settings). This should fix itself when that other PR is merged and I do the work I'll need to fix the handful of lines types I had leave partially unfinished in this PR. But, I will also see what I can do so this can't happen.
For the record, if you now click the line and press Ctrl+R, it will reset a bit more properly, but not quite - the line with now huge the notes too closely. That's because the other bug was preventing me from getting the right "autoplace minimum distance" setting for this line type (and a couple of others). If you check the "Minimum distance" property (new with my PR) in the Inspector, you'll see that on load and taking the reset, it was set to -999, which is what my code does for lines that extend into the staff. This is to keep their position fixed within the staff even as the skyline changes, rather than continue to "float" as other elements do. When you hit the reset button in the Inspector for this line, the "Minimum distance" goes to 0, but it should be 0.7sp according to the style setting. It's because of the other bug that this isn't working right. If you then set it to 0.7sp in the Inspector and hit "Set as style", you'll be seeing what you should have been seeing all along. Well, you would if "Set as style" were available for this line type, but that the other bug again.
I explain all this in case in gives insight into what is going that might aid in your testing. Everything my PR is doing here involving, it is doing by changing the "Minimum distance" settings as necessary for elements as you move them. So you can also get other interesting and useful behaviors by modifying this setting manually in the Inspector - like forcing some particular element to appear higher above the skyline than normal and continuing to float as the skyline changes.
There is a also a problem with staff text: see the attached 2.x file, measure 7. It should be above the beams but is now colliding with the notes.
Another good find, indeed, the "reset" option in 2.x import is not behaving as it should and is instead trying to force the default offset to be applied. Shouldn't be hard to fix.
Here's an updated build (again, for Windows) should anyone wish to continue testing:
https://ci.appveyor.com/api/buildjobs/rfcx1oxrueuxa352/artifacts/MuseSc…
It fixes the issues with the reset option on import of 2.x, plus it should do correct things with the handful of line types not handled by the previous build (text line, let ring, palm mute).
Another new thing it does - it detects if you drag or otherwise move an element to the opposite side of the staff, and automatically converts it between above and below placement, adjusting the offset and minimum distance as necessary so it should "stick" on release. I also added a bunch of missing element types to the "X" command.
"Another new thing it does - it detects if you drag or otherwise move an element to the opposite side of the staff, and automatically converts it between above and below placement"
Result visible in Inspector, indeed. Good one! Better and better, and unless I missed something, I no longer see any limits to this great feature of disabling (or not) with various ways the automatic placement.
Thanks for the addition for the "X" command for some elements. I don't know if there's much left: I see one, at least, that's missing: Fretboards Diagrams. The "X" is inactive.
Of course, you can disable the placement with the shortcut "=", but this command "X" is so natural (in the sense, anchored in our habits) that we are/I am surprised to see these diagrams not responding in the same way.
Thanks again for the feedback - I have now added support for flipping fretboard diagrams to the PR.
OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.1.0.6792, revision: 354737f
Expected result: The "Minimum Distance" should recover to 0.5.
Actual result: The "Minimum Distance" stays at the lower value.
Expected result: The "Minimum Distance" should recover to 0.5?
Actual result: The "Minimum Distance" assumes another value.
In reply to Open the attached file and… by geetar
This is currently by design, but open for discussion. If you move an element closer to the staff than currently allowed by autoplace, the only way to accomplish this is to decrease autoplace min distance, so that's what we do. But moving it further away doesn't require such a change. It depends on the result you want later, as the skyline changes. Do you want the element to start floating up immediately, or do you want it to stay put until the skyline catches up to it?
It's certainly possible to change it to always adjust min distance, which means the element will keep its relative position to the skyline if the skyline changes.
But the other thing to consider is, we have no way of knowing if the current min distance value is there because it was set automatically last time you moved an element, versus maybe you set it deliberately using the Inspector and don't want it messed with. I think maybe that's a good argument for leaving it alone when changing it isn't actually needed.
Result: The Y-offset incorrectly reads -4.
Result: The text moves to the true Y-offset = -4 position.
This is normal - same as 3.0.5 - and exactly one of the existing I worked hard to preserve. When autoplace is enabled and doing its normal job, the offset in the Inspector reflects the default position, not the actual position. And there is a nice advantage to this - it means you can select a bunch of autoplaced elements at different heights, then easily align them by using the spin box in the Inspector. The elements closest to the staff start moving sooner, because their true offset is closer to their default. I rely on this quite a bit actually.
Normally if you hit the down arrow on a text like this, you see the offset go down (to -3.90 sp) but the element doesn't move - autoplace just works that much harder to keep it in place. My PR convert converts that into the real offset the moment you move an element into the skyline.
In MS 3, the Inspector offset reading sometimes reflects the actual position of the element, other times it does not. This is clearly illogical and confusing. Surely, the offset readings should always reflect the actual position of the element, as they did in MS 2.3.2.
2.3.2 didn't have autoplace, so much is different. Again, there are very good reasons for autoplace not to automatically change the displayed to reflect the adjustment, one of which I already described. There are of course other reasons why maybe in some cases one might wish the offset to reflect the autoplace adjustment, so it's worth startitng a forum discussion about that. But again, my goal here was 100% compatibility - to not change any more than necessary.
In reply to 2.3.2 didn't have autoplace,… by Marc Sabatella
Quite clear that both values are intersting.
Logical conclusion, the inspector should be enhanced to display both.
The PR is merged! So fixed in https://github.com/musescore/MuseScore/pull/4982/commits/6a33ef58974869…
As for showing the "actual" offset in the Inspector, it's certainly possible, although since it's a generated value, not really a user-set one, it's not really clear how that might look. Feel free to start a forum discussion.
Regarding https://musescore.org/en/node/288431#comment-917697 and my response immediately following, about the behavior of min distance when moving an element away from the staff:
Dmitri had the same observation, and I was on the fence about it anyhow, so I'm considering this enough of a consensus that I've submitted a PR to change that (along with addressing a few other small details raised by Dmitri. See https://github.com/musescore/MuseScore/pull/5018
Automatically closed -- issue fixed for 2 weeks with no activity.
might not be the right place to ask but .....
is there a shortcut for left hand fingering numbers? for example on a guitar having a "D" chord is there an easier way than clicking on the "1" with the mouse from the fingering palette to add to the "A" on the third string, then mousing over again to get the "2" to put it on the first string etc....
I see when I hover over a number the tip pops up saying "LH Guitar Fingering" as if there were a keyboard shortcut to ease the entry.
Is there anything like this?
thanks
This indeed isn't the right place, please use the forum rather than an issue that is closed since almost 3 years.
But no, there isn't a shortcut for that
In reply to This isn't the right place,… by Jojo-Schmitz
Thanks