Note's default edit behavior (leading space of 3.2 versus chord displacement of 3.3)
Am I the only one who prefers the older 3.2 leading-space default of a note when using the edit shortcut rather than the newer chord-displacement default? I used it for a slick keyboard-way of giving extra space to the beginning of a measure for dynamic markings and other expression texts, and I find this to be a more prominent action than displacing chords, generally speaking. Upon upgrading I now no longer have that action available in the same way (not on topic, but just so I have no ability to add an accidental while in note-edit mode, nor can I add an accidental while building chords through interval shortcuts instead of tones.)
Comments
I personally prefer the move chord option.
In reply to I personally prefer the move… by mike320
I just realized that [Shift+Left/Right] will do the leading also, so instead of losing the ability, the ability is gained to do both quickly, i.e., chord-offset and leading space. For what it's worth, this is definitely an agreeable change.
In reply to I just realized that [Shift… by worldwideweary
That was the idea, so I'm glad you figured it out :-). The change to allow leading space adjustments by dragging was nice (that came in either 3.1 or 3.2), but it interfered with some pretty common use cases where you really want to just move the position (eg, fiddling with position of overlapping multiple voice. You can also get either behavior via drag, using appropriate modifiers.
In reply to That was the idea, so I'm… by Marc Sabatella
Thanks for the tip about the mouse also, as that is useful for a quick and very large motion compared to the 0.10sp per arrow press. In the process of experiment, I may have found a bug depending on the intentional design of the [reset shapes and positions] command related to lead-spacing:
1) [ctrl]+[drag], chord-offsetting occurs
2) [alt]+[drag], leading-space occurs
[ctrl]+[r] is supposed to revert a note/element to [reset shapes and positions/revert to default], yet only the chord-offsetting is reset upon doing so. I.e., chord-offset will be reset to 0 upon a [ctrl]+[r], but if the user varies a note's lead-spacing, [ctrl]+[r] doesn't revert it to 0. Is this intentional, or should it be this way?
In reply to Thanks for the tip about the… by worldwideweary
I would say it should be this way. After all, leading space is not a property of the note itself, but of the segment as a whole. It's a bit of a lie that it shows in the Inspector for notes, but that's because we don't otherwise have a convenient place to hang it. Given there may be other notes on other staves that may also relevant in why you might have applied the leading space adjustment, it would be most unexpected if resetting one note affected others too. Making you reset it more explicitly is one way to lessen the risk of accidental reset of a property that other notes may be relying on.
In reply to I would say it should be… by Marc Sabatella
Makes sense. Thanks for your input.
In reply to Makes sense. Thanks for your… by worldwideweary
Update: Another question/observation - with the information as mentioned so far in this thread, what of rests? Notice that rests do the exact same behavior with [shift+arrows] or [arrows] in edit mode. That is, there is no lead-space change using shift+[left/right], as was expected based on how it works for notes, but rather regular offsetting.
Is this intended? It seems slightly non-congruous rather than an intention.
In reply to Update: Another question… by worldwideweary
Probably an oversight. The code to handle this was added to Note::editDrag() but there is no corresponding code for rests. Presumably that could be fixed via some copy/paste.
In reply to Probably an oversight. The… by Marc Sabatella
#297615: Edit behavior: shift+arrows do not change leading-space upon a rest.
It looks like 3.4 (or somewhere before that like 3.3.1-3.3.x) erased the ability to SHIFT+Left/Right to offset leading space while in edit mode of a note. Shift or non-shift, while in edit mode, only chord-offset occurs for me. I really liked the leading-space ability with the keyboard quickly. Any strong reason why it was omitted, or am I missing something?
In reply to It looks like 3.4 (or… by worldwideweary
I suspect it got lost accidentally in the redesign of edit mode for single-click, perhaps in this commit:
https://github.com/musescore/MuseScore/commit/767fcae3b149777711d354a0a…
In reply to I suspect it got lost… by Marc Sabatella
Thanks: #299214: Reimplement Shift+L/R for leading space while in edit mode upon notehead
In reply to It looks like 3.4 (or… by worldwideweary
For the record: apparently leading space adjustment can now be made with mouse drag directly without entering edit mode. And in edit mode, drag now works in vertical and horizontal directions in a "useful" (to some, I suppose) way. That was the reaosn for the rewrite of that particular chunk of code. But no good reason I can see to have lost Shift+left/right along the way. So hopefully we'll see that come back.
In reply to For the record: apparently… by Marc Sabatella
Hopefully... :)
(still hasn't been re-implemented, although at least the mouse does continue to perform lead-space adjustments here with [ctrl+drag] outside of editing.)