Slurs/lines etc. - what difference does "edit mode" actually make?

• Aug 26, 2021 - 12:59

The manual explains what edit mode is supposed to do for slurs/hairpins/other lines etc. - but from what I'm seeing all those things work even without entering edit mode - just selecting a single element then using TAB to select a particular grip handle allows you to make all the same modifications.
The only thing the command seems to do is automatically select the "end" grip handle, and change the text in the status bar to say "Edit mode". From a brief look through the code it doesn't seem any of the cursor key operations etc. are treated differently by such an element whether it's in edit mode or not either.
Is there a specific example of an operation that only works when such an element is in edit mode?


Comments

The differences is what handle gets selected, on a single click it is the center one, the one that moves the entire slur, on double-clock it is the rightmost one, to make the slur shorter or longer, or tilt it

In reply to by Jojo-Schmitz

Actually there is quite a difference after all - in Edit mode the only commands that work are those that apply to editing the current element, plus the File/Help/preferences commands. All other commands related to score manipulation/navigation/note input are disabled.
Interestingly even the clipboard operations don't work in edit mode despite being shown as enabled in the menu.
One interesting difference between text editing and line/grip element editing is that for the former "undo/redo" rolls up into a single action after you exit text editing mode, whereas that's not true for the latter.

In reply to by Dylan Nicholson1

Some other observations:
a) undo for a line element exits edit mode (enabling all the other commands that were previously disabled)
b) edit mode is permitted for layout breaks, and that appears to be the only way to manipulate where they're shown on the score (not that this is particularly useful except perhaps to get them out of the way of your notation)
c) brackets are the only type of element with grip handles that explicitly require activating "edit mode" in order to manipulate them (but in MU4 currently this is not true, nor do I see any reason it should be)
d) Alt+Shift+E doesn't work when you click on a key/time signature in a score with multiple staves, despite it being available in the context menu. You have to use ctrl+click to ensure only the time/key signature in the current staff is selected, and moreover, for key signatures must be first instance - i.e. it can't be a key signature automatically shown on a subsequent system. But if I wanted to "nudge" a time/key signature left or right, I'd most likely want to do it across all staves surely...and it doesn't seem possible to modify the position of key signatures automatically shown on subsequent systems at all.
e) Clefs and measure numbers seem to be the only types of element that don't have edit mode at all. But it would seem just as useful to be able to reposition them with the cursor keys as other elements. Instrument names don't allow explicitly activating edit mode, but can still be repositioned with the cursor keys. Tuplets can only enter edit mode if they have a bracket showing - but you can still manipulate the grip handles without using edit mode, even with no bracket!
f) Edit mode for Coda symbols seems a bit unexpected, it goes into text editing mode instead.

In reply to by bobjp

Er, nope, Fn+F8 on my keyboard activates the Windows screen projection options (for controlling how multiple displays work I guess, I don't have one to test with currently, never used).
F8 shows/hides the inspector but doesn't change the focus to it. I can't seem to find any way to use the keyboard to switch between various windows/dock-panels of MuseScore at all.

In reply to by bobjp

Well it looks like the focus is on the inspector (specifically the 'visible' label), which is a good thing, but are you saying you can get that to happen just using the keyboard if the focus had previously been on the score window? The only handling for "F8" in MuseScore that I can find looking through the code etc. is that by default it's mapped to "show/hide inspector", which does indeed make that window appear to disappear, but I'm not seeing it get the focus at all. Are you sure you haven't mapped Fn+F8 yourself? (though I certainly can't see any actions or indeed any code that would trigger setting the focus to the Inspector panel).

In reply to by Dylan Nicholson1

BTW there's a discussion about it here: https://musescore.org/en/node/299941
On further testing I discovered that the TAB key for elements that don't have grip handles (line-based elements) does in fact change the focus to the Inspector - but only if it's docked.
If it's undocked as per your screenshot it doesn't work and there appears to be no way of changing focus to it using the keyboard.

(In v4 at this stage not even that much works, you have to use F6 before using TAB to tab through all panels until you get to the "inspector", or properties panel as it's now called, but you still can't do so if it's undocked)

In reply to by Dylan Nicholson1

I created a new score and selected the key signature. Then I hit fn+f8. The result is in my picture. This is a completely stock MuseScore. I don't map or change anything. I don't hardly use any keyboard shortcuts.

I notice that my desktop keyboard doesn't have an fn key. I haven't check too many of my other computers. But on my main laptop, this is how fn+f8 works. No idea why. Or if it's the way it should work. Perhaps differences in various keyboards and computers explain some of the things you are finding.

In reply to by bobjp

@bobjp And it's different if you press just F8 alone? What if it's docked? What happens if you press it (or fn+f8) a second time?
I can't see how what you describe is possible from the code. Fn+function key on most keyboards doesn't even send keystrokes that can be intercepted by applications.

In reply to by Dylan Nicholson1

Nothing happens if I just push f8. The function keys do double duty. f8 key primary function is to fast forward audio in a music player. F11 keys turns off my speakers. In order to get actual f8 action, I have to hit FN+f8. This seems to be an internal OS feature independent of MuseScore.
Same thing happens docked or not.

In reply to by bobjp

That's bizarre.
Just plain "F8" is mapped to an action that shows/hides the inspector but there's no code to set the focus to it, and it certainly doesn't for me. In fact as I said, when undocked, I can't find any way at all to set keyboard focus to the inspector window (if it's docked and the current selected element doesn't have grip handles then "Tab" works).

In reply to by Dylan Nicholson1

In MuseScore 3, Tab / Shift+Tab moves between all controls in the current window, and Tab usually goes straight to the Inspector. Except for a couple of particular cases like lines or barlines where instead it moves between handles. That's a regression introduced when the new behavior of lines not needing edit mode was introduced.

In MuseScore 4 the plan is for F6 to move from one section to the next t- not sure what these are called, but the things we'd call docked windows in MuseScore 3. Apparently it's still very much a work in progress though.

In reply to by bobjp

Good point about double-click, that does actually start edit mode for element types that support it though for key/time signatures in a multi-staff score, you need to use control-double click.
Double-click on instrument names is an exception - that brings up the score properties dialog.
For text-based elements that are already selected just single click is enough actually.

In reply to by Dylan Nicholson1

It's worth noting that the relatively recent changes that soften the line between selecting a line and putting into edit mode were a partial implementation of one of @tantacrul's very first design specs. I know he's expressed thoughts about wishing the see the design implemented more fully. Definitely worth continue that conversation.

I'm actually seriously looking into whether we need edit mode at all, for any type of element.
The main issue is that currently elements respond to dragging via the mouse very differently depending on whether they're in edit mode or not:

notes
- normal mode: dragging vertically adjusts pitch, CTRL prevents modification, ALT/SHIFT have no effect. Dragging horizontally adjusts leading space, note you must drag right first (the default and minimum is 0). CTRL/ALT/SHIFT have no effect.
- edit mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vertical modification, ALT turns off auto-place, SHIFT prevents ANY modification (appears to be a bug, as SHIFT is first treated as preventing horizontal modification, but later treated as meaning modify leading space, which can only be modified horizontally!)

rests
- normal mode: for whole rests dragging does nothing, for others dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.
- edit mode: for all rests (inc. whole), dragging vertically/horizontally adjusts x/y offset, CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents ANY modification (same bug as for notes)

clefs
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: not available

key signatures
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.

time signatures/accidentals/articulations/ornaments/breaths&pauses/tremolo beams/fret diagrams...
- normal mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.
- edit mode: same as normal mode

beams
- normal mode: dragging only affects beam height/angle depending on grip selected. CTRL prevents any mod., ALT/SHIFT have no effect
- edit mode: same as normal mode except that ALT turns off auto-place

lines (with grip handles, incl. hairpins, slurs etc.)
- normal mode/edit mode: dragging vertically/horizontally adjusts x/y offset of whole item or individual grip handle if initially clicked on. CTRL prevents vert. mod., ALT turns off auto-place (, SHIFT prevents horiz. mod. Certain grip handles can never be dragged left/right (e.g. the one to control hairpin width) or up/down (e.g. the rightmost handle for a hairpin with "allow diagonal" off).

barlines
- normal/edit mode: dragging lower handle controls barline span. CTRL affects just current barline (vs all on staff), ALT/SHIFT have no effect

brackets
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: dragging lower handle controls bracket span. CTRL prevents modification. ALT/SHIFT have no effect.

instrument names
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: not available

  • note however that you can adjust x/y offset using the keyboard

text (including tempo, rehearsal marks, dynamics, repeat markers, fingerings, chord symbols etc. etc.)
- normal mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT turns off auto-place, SHIFT prevents horiz. mod.
- edit mode: dragging changes what text is selected. CTRL/ALT/SHIFT have no effect (in MS Word these effect the "unit" of selection is, e.g. word/paragraph)

frames
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT/SHIFT have no effect.
- edit mode: for text frames, dragging where there's text is used to select text, dragging outside this is as per normal mode. For horizontal/vertical frames, dragging stretches the height/width of the frame. CTRL prevents modification, ALT/SHIFT have no effect.

breaks
- normal mode: dragging pans the whole score around. CTRL doesn't affect dragging but does toggle selection. ALT turns off auto-place, SHIFT has no effect.
- edit mode: dragging vertically/horizontally adjusts x/y offset. CTRL prevents vert. mod., ALT has no effect, SHIFT prevents horiz. mod.

spacers
- normal/edit mode: vertical dragging adjusts the height of the spacer. CTRL prevents modification, ALT/SHIFT have no effect.

In principle virtually all this (with improvements) could be achieved by being smarter about what various keyboard modifiers mean rather than needing an explicit "edit" mode, which I believe would make things easier both for users AND simpler at a code level (meaning less bugs etc.!).

In reply to by Dylan Nicholson1

Indeed, I believe @tantacrul was also working towards that goal. Although I'm not sure one would literally want to apply to all elements - even text?

I will say that personally I move elements horizontal vertical position probably about 10 times as often as I ever fiddle with handles for fine-tuning shape or changing anchors (e.g., correcting any errors in the range I originally selected when applying a line). So I do hope any changes made in this respect don't end up making this any more awkward than it already is (it's rather a pain currently that selecting a line doesn't immediately allow Ctrl+Up/Down).

In reply to by Marc Sabatella

"Text edit mode" is obviously quite a special case, that's not going anywhere (I already did much of the work there to get it to where to needs to be, and I'd like to think it's an improvement over v3, e.g. undo works for bold/italic/underline when only part of the text is selected, and it now never tries to draw musical symbols in the wrong font/format, which did happen quite a bit previously).

At this stage I'm just trying to get everything else working in v4, but that did require writing a bunch of extra code to support edit mode for all elements. None of it's been merged yet, and I'm more than willing to discard it in favour of something more user- and developer friendly.
For instance the SHIFT+drag bug is still present in what I've done so far, because the code to restrain horizontal mode while SHIFT was done was already in place at one level, and the code for it to be interpreted as "changing leading space" was ported as is from v3.

One significant issue with edit mode in v4 especially is that there's no user feedback at all that you are in edit mode - not even the notation input toolbar icons are greyed out (they should logically be and their attached actions are unavailable, but that doesn't appear to be implemented). And there's nothing in the status bar like there was in v4.
So if we want to maintain "edit mode", there's still a lot of work to do in v4. The question is whether it would be better directed into discarding the need for it.

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