Configurable nudge distance in Edit Mode

[rpatters1]

Your idea

I would like to be able to configure the arrow nudge distance when editing items in Edit Mode (esp. elements added from "Master palette: Symbols".)

This could perhaps be added to the program preferences.

Problem to be solved

Currently, this doc page implies that the nudge distance is hard-coded at 0.5sp and (it appears with testing) that the ctrl/cmd nudge distance is 1.0sp. Those are simply not granular enough for the kinds of minute adjustments I'd like to make. I can of course drag with the mouse, but those edits are imprecise.

Prior art

Finale configures the nudge distance in pixels. (Preferences->Edit panel) This means you can get finer or coarser nudge granularity by changing the zoom percentage. In my experience, measuring nudge distance in pixels is not all pluses. There are minuses, the chief being that changing the zoom percentage can be disruptive to one's workflow. Especially on Finale. Another is that nudge distances are imprecise in some zoom percentages.

I would be happy with configurable distances in (fractions of) spaces. I would probably change the 0.5sp to 0.25sp but leave the ctrl/cmd distance at 1.0sp. FWIW: on Finale I have the nudge distance set to 1 pixel.

Additional context

No response

Checklist

• [X] This request follows the guidelines for reporting issues
• [X] I have verified that this feature request has not been logged before, by searching the issue tracker for similar requests

[MarcSabatella]

I agree, which is why I submitted the same request some time ago ;-)

https://github.com/musescore/MuseScore/issues/13438

[bkunda]

This does indeed seem very similar to, although slightly different from #13438. Hence we'll leave it open.

[rpatters1]

The slight difference I see between this request and #13438 is that I was thinking of separate keyboard increment settings in the program options and the earlier one envisioned tying it into the snap-to-grid settings. (It is unclear to me if the snap-to-grid settings are in the doc or program options.) In fact that issue seems more focused on snap-to-grid than on nudge keys in edit mode.

I am thinking of taking this on as my next project, but I'd like to understand if there is a consensus around scope and approach.

1. I am going to suggest making it a separate setting from the snap-to-grid distance. There is a chance of user confusion if the grid setting is controlling the nudge keys when it is turned off. The most logical place to me for the setting seems like Preferences->Canvas->Miscellaneous. There would be a small and larger distance specified in fractional space increments (specified with decimal).
2. Are the drag and keyboard snap behavior in-scope if we separate this from snap-to-grid?
3. I agree that the fractional specification for the grid is cumbersome, but I also view it as out of scope if we agree on my suggestion in 1.

In fact, if we take the approach of it being a Preference, I don't see it addressing #13438 at all beyond removing the nudge increments from its scope. I think it probably would resolve #16862.

[MarcSabatella]

I'm not seeing it being 0.5 anymore with 4.4.2 - seems like 0.1. But I don't see any relevant code changes, so I wonder if there is something else going on.

[rpatters1]

I'm still seeing the 0.5 in 4.4.2, provided you go into Edit mode. (That is, right click the item and select "Edit element".) Otherwise, if you simply click the element, the (vertical) arrow keys seem to nudge by a context-sensitive amount. For example, articulations nudge by a tiny amount, perhaps 0.1. But rests nudge by a full space.

I'm wondering why there should be a difference in behavior and what the proper solution is.

[MarcSabatella]

For rests it is definitely by design, since there are specific rules of notation governing their position and the default behavior should honor them. You should still be able to do fine tuning in Properties. For articulations, it’s certainly possible this was also by design, but I don’t really know.

[krasko78]

I think @pacebes has done a very good analysis of the problem in #13438 and I agree with his suggested fix: to comment out those raster-related lines 131-136 in notationinteraction.cpp. They had been added in commit 5e7e556 to tackle #9902. Personally I am struggling to understand why. Maybe we should ask RomanPudashkin? I've had this fix implemented in my fork for some time now and have not noticed any issues but I could be missing something. We could keep a minimum for the nudge distance but a low enough one, e.g. 1, just in case.

With the raster fix I find the hard-coded value of 0.1 for nudgeStep gives me enough precision: 1px on my machine. We could expose this value as an editable setting if it is not good enough for everyone. Btw: on my computer the spatium is 24.8 so 0.1 * 24.8 = 2.48. @pacebes has cited slightly lower values for him in #13438.

Another [strange] thing is that beams are treated differently and nudge by larger amounts so even with the raster fix they don't nudge by 1px. As a result I have this code for beams also commented out in my fork. It is in the other nudgeDistance function that immediately precedes the one with the raster lines: lines 109-117 in notationinteraction.cpp.

More fun facts: the Alt key is supposed to give us 0.01sp (so 10 times more precise than without any key modifiers) but it has been disabled. :( And, for beams, the Alt key would give us (had it not been disabled) 4sp which is inconsistent: for beams the Alt key would cause much coarser nudging whereas for the other elements much finer. :)

[ghost]

From 4.0 beams were hardcoded to (sort of) snap to multiples of 0.25sp, regardless of grid settings, so that they would always appear at geometrically valid positions. It doesn't really work properly because when dragging the value still changes smoothingly (in at least 0.01sp increments, or so the UI shows) - the beams will just be drawn at the rounded positions. Similarly, the up/down keys will move by 0.25 but that will change a value of (e.g.) 4.39 to 4.14 or 4.64, rather than 'snapping' to 4.25 or 4.5.

So it's arguably a bit useless, or at least confusing, as it is, and even if worked properly would need to be turn-off-able for special cases (including for cue notes, or staves with a different distance between lines, etc).

[krasko78]

"geometrically valid positions" - does this mean that from an engraving perspective beams are permitted (by engraving standards) only to start and end on 0.25sp locations?

[ghost]

Correct. As it is, the beam positioning algorithm will only put beams at 0.25sp positions, unless a) they are resized (i.e. cue notes, grace notes, etc), or b) for cross-stave beams where it's a bit fuzzy.

[krasko78]

Good to know, thanks!