Note's default edit behavior (leading space of 3.2 versus chord displacement of 3.3)

• Nov 22, 2019 - 05:31

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.)


In reply to 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 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 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 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.

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 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.

Do you still have an unanswered question? Please log in first to post your question.