[MU4 Issue] Improvement: use "snap to grid" configuration to set keyboard nudge increment

[MarcSabatella]

Not a regression; snap to grid works as it did in 3.6.2. However, with the change to the how keyboard adjustments work (they formerly moved in 0.1 sp increments but now it's 0.5 sp, which several people have complained is too coarse), I think some simple enhancements to the snap to grid functionality could make every happy (!):

1. Use the grid configuration settings to determine the nudge increment (whether "snap to grid" is actually enabled or not)
2. Make both the drag and keyboard snap behavior apply to line handles (including tuplet brackets), not just position
3. Replace the fractional specification for the grid with a decimal one

To be clear, when I mention keyboard nudge, I'm talking about behavior when select an element and moving it directly with the keyboard, not the increment used for the offset spin box. Although, that too could be nice!

[rgreen5]

Having an option to be able to adjust in 0.1 sp. increments is essential. At present all the "adjustors" (keyboard arrows, properties panel spinners) work in 0.5 sp. increments. This is too coarse.

See also #13476. and #16862.

[pacebes]

Hi

I'm trying to understand what this is issue is about or if it is now obsolete and https://github.com/musescore/MuseScore/issues/24721 should be implemented instead. Sorry if I ask silly questions.

Is this about the "steps" when you move with the keyboard something like this: ?

I think it moves smoothly. I have been looking into the code and it seems that the space moved when the cursor key is pressed depends on:

• editData.element->spatium(). I'm not sure but I think this value depends on the score (20.3998 was the number in the score I used for testing)
• Without modifiers: mu::engraving::MScore::nudgeStep. This value is set to 0.1
• With modifiers (Control, Alt)

What is proposed here is to change this behaviour so it uses the values from this dialog ??

[MarcSabatella]

When I first filed this issue, the default nudge step was 0.5 sp, but it does seem like it changed to 0.1 at some point? Or maybe it is 0.5 for some elements and 0.1 for others? Key and time signatures at least seem to be 0.5, which is probably fine.

Anyhow, I'm not sure then this issue is still real.

BTW, Ctrl+cursor is meant to move in 1sp increments - that works as expected for me and shouldn't be changed. Alt+cursor is not normally a thing - actually Alt+Left/Right navigate to another element. But there might be certain element or certain modes where it is special-cased?

[pacebes]

When I first filed this issue, the default nudge step was 0.5 sp, but it does seem like it changed to 0.1 at some point? Or maybe it is 0.5 for some elements and 0.1 for others? Key and time signatures at least seem to be 0.5, which is probably fine.

Anyhow, I'm not sure then this issue is still real.

Ok, thanks. I'll look for another free available issue in https://github.com/orgs/musescore/projects/30/views/1. May be it could be a good idea to remove this issue from this page

BTW, Ctrl+cursor is meant to move in 1sp increments - that works as expected for me and shouldn't be changed. Alt+cursor is not normally a thing - actually Alt+Left/Right navigate to another element. But there might be certain element or certain modes where it is special-cased?

Yo are right... There is also a different increment for Alt + Cursor in the code, but I think there is something previously in the code that prevents this (as you say Alt+Left/Right navigate to another element)

    MScore::setNudgeStep(0.1);     // cursor key (default 0.1)
    MScore::setNudgeStep10(1.0);     // Ctrl + cursor key (default 1.0)
    MScore::setNudgeStep50(0.01);     // Alt  + cursor key (default 0.01)

[MarcSabatella]

Well, I'm confused, because https://github.com/musescore/MuseScore/issues/24721 was submitted only a few weeks ago and it suggests the nudge step was still 0.5 sp at that time. I am not aware of any changes made that recently. And in fact I don't see any relevant changes to this part of the code since two years ago. So now I'm wondering if there is some other setting somewhere that is resulting in sometimes seeing 0.5 and sometimes 0.1. It would be good to understand what is going on here before closing the issue.

[pacebes]

Ok.

You are right According to https://new.musescore.org/en/handbook/4/adjusting-elements-directly

Use Edit mode.

To enter Edit mode, either

Right-click → Edit element on an element on a score, or
Select an element on a score, use the keyboard shortcut F2, or
Select an element on a score, use the keyboard shortcut Alt+Shift+E (Mac: ⌥+Shift+E)

Then, in Edit mode, press the keyboard arrows ← → ↑ ↓ to move the object in step of 0.5 sp, or

This can be used to move the notes or ornaments (or others) with the arrows. I have tested it and I think it is also moved smoothly (may be 0.1).

Do you have any example where the movement is too coarse (to avoid looking a needle in a haystack) ?

[MarcSabatella]

~Not anymore~. Articulations. Add an articulation to a note, press F2 to enter edit mode. Cursor keys move in 0.5 sp increments. Maybe that's by design? But I would have sworn it was pretty much all elements at one time, hence my issue not making reference to which specific element (my bad).

[pacebes]

You are right

Some elements (notes, articulations) move 5 times the space others move. I am trying to figure out why.

[pacebes]

Hi @MarcSabatella

There is some code within notationinteraction.cpp to ensure there is a minimum distance to move notes or articulations (notations...) :

static qreal nudgeDistance(const mu::engraving::EditData& editData, qreal raster)
{
    qreal distance = nudgeDistance(editData);
    if (raster > 0) {
        raster = editData.element->spatium() / raster;
        if (distance < raster) {
            distance = raster;
        }
    }
    return distance;
}

• raster is mu::engraving::MScore::hRaster(), which in turn is DEFAULT_GRID_SIZE_SPATIUM: 2. Therefore it is always > 0
• Initial distance value (from nudgeDistance(editData)) is 2.03998 (I presume is 1sp)
• As spatium/raster is 10.1999 is bigger than 2.03998 (5 times, AKA 5sp) ... it will always return 5sp as the minimun movement

What I mean is that there is some specific code to ensure the minimum movement is 5sp).

It would be really easy (I have tested) to return to 1sp just deleting these lines:

/*
    if (raster > 0) {
        raster = editData.element->spatium() / raster;
        if (distance < raster) {
            distance = raster;
        }
    }
*/

... but this overloaded method is just to ensure this minimun space movement.

So... What should we do ?

[MarcSabatella]

I'm not familiar enough with this area of code to say, but hopefully someone else has insight.

[MarcSabatella]

The situation is improved now, but still not quite ideal. The raster distances set in the configure grid dialogs are honored - actually they are honored even if you turn "snap to grid" back off, which is kind of nice if a little surprising. However, these settings are only fully preserved if you save the score, and only for that score. If you open a different score - or close without saving and then reopen - the state of checkbox is remembered, as is the grid configuration, but they don't actually take effect. If you then click the configure the grid button, you'll see the values you entered there, and if you press OK, now they take effect.

So:

1. select an element (say, the left grip of a tie)
2. press Right - by default you'll see 0.5 sp nudge
3. in Properties, set Snap to grid, then Configure grid
4. set 1/10 for vertical and horizontal
5. repeat the nudge to confirm it worked - nudge is now 0.1 sp
6. close without saving
7. reopen
8. try the nudge again - it's back to 0.5 sp
9. return to Properties and you'll see Snap is enabled
10. press Configure grid and you'll see it still says 1/10 sp
11. press OK
12. try the nudge again - it's 0.1 sp again
13. save, close, and reopen
14. try the nudge yet again - now it remains 0.1 sp

[pacebes]

HI I'll take a look at it!

[pacebes]

It seems that "Properties-Appearance-Configure to Grid-Edit grid" is only taken into account when you open the "Edit grid" dialog and Press "OK" as you say.

You can check that the settings where correctly stored in "MuseScore4Development.ini":

[ui]
application\raster\isSnappedToHorizontalGrid=true
application\raster\isSnappedToVerticalGrid=true
application\raster\vertical=15
application\raster\horizontal=16

Now

• Start MuseScore
• Open a new Score and move a tie => you get a 0.5 sp nudge
• Open a "Properties-Appearance-Configure to Grid-Edit grid" and press "OK" without changing nothing
• It now gets the right (stored) nudge for every new Score until you exit MuseScore

So it seems that this property is not read when MuseScore is started. I will try to see why

[pacebes]

There is a way to restore the previously saved values within "NotationConfiguration::init()". I think it's the best way to change the code. The patch would be:

diff --git a/src/notation/internal/notationconfiguration.cpp b/src/notation/internal/notationconfiguration.cpp
index 653695df6f..bcf32f7d06 100644
--- a/src/notation/internal/notationconfiguration.cpp
+++ b/src/notation/internal/notationconfiguration.cpp
@@ -392,8 +392,9 @@ void NotationConfiguration::init()
     mu::engraving::MScore::warnGuitarBends = warnGuitarBends();
     mu::engraving::MScore::defaultPlayDuration = notePlayDurationMilliseconds();

-    mu::engraving::MScore::setHRaster(DEFAULT_GRID_SIZE_SPATIUM);
-    mu::engraving::MScore::setVRaster(DEFAULT_GRID_SIZE_SPATIUM);
+    // Restore stored grid size values
+    mu::engraving::MScore::setHRaster(settings()->value(HORIZONTAL_GRID_SIZE_KEY).toInt());
+    mu::engraving::MScore::setVRaster(settings()->value(VERTICAL_GRID_SIZE_KEY).toInt());

     context()->currentProjectChanged().onNotify(this, [this]() {
         resetStyleDialogPageIndices();

And it works. Should I create a PR or should it be changed anyway?

[pacebes]

Hi

I will create a PR and we can iterate over it .