Note-Entry: a few suggestion for changes.

• Oct 3, 2019 - 00:57
Reported version
3.2
Type
Functional
Frequency
Once
Severity
S5 - Suggestion
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project

Suggestions for making note-entry & editing easier and faster:

  1. Allow Element Selection (Alt+Left/Right) to be functional while in Note Entry mode, resulting in the loss of Note Entry if the element is not a note, but if it is a note within the same chord as the N.E. slot (since Alt+L/R also selects a chord's notes, which is currently unavailable while in note entry, similar to ALT+Up/Down which is functional while in N.E.), stay in note entry. The question is open as to whether this action should stay in note entry if the next element is the next chord. Should it stay in Note-Entry or exit note entry? Personally would keep it in note entry this way, equivalent to the standard left/right arrows. If this were done, a further question remains: if the user entered into editing an element from Note entry, when escaping or going back to the previous element, if it's a note, should Note Entry continue automatically?

  2. While in Element Edit mode (mainly node offsets for lines and slur alterations), allow for Element Selection (Alt+Left/Right) to easily exit edit mode without having to "escape" and then do so, while keeping regular Left/Right/Up/Down for the offsetting of the nodes. As it is currently, Alt+Left/Right do nothing while editing, but if this were changed, they would.

  3. Not only #2, but allow activating Note-Entry from within Element Edit mode so that the result would be to select the slot of the note to which the element is attached for beginning N.E. (or potentially the note to which the end node is attached, which might be the better option), of course additionally exiting the editing of the element. If the element is not attached to a note but is of the measure, select the first duration of the measure for note entry .

  4. Here's one that might ruffle some feathers: automatically enter into Element Edit mode when selecting a line. The question is: why would a user want to click a line or slur without going into edit mode? To move it? Sure, the user can drag with the mouse without entering into edit mode (but they can't with the keyboard arrows!), so then if this is desirable, allow upon clicking with mouse to drag still, but upon release of clicking, it goes into Edit mode (at least it's an idea). The Inspector is already accessible with or without being in Edit mode, so numerical values can be input as it is in mere selection or in edit mode. Keep this behavior, and jump into edit mode automatically. There's nothing lost by this except for the fact that the mouse as it is can click anywhere on a slur to move it while not in edit mode, whereas in Edit-mode, the user would have to click the middle node. But again, if edit mode didn't commence until after the user "unclicked", then this wouldn't be an issue.

Actually, if this were done as with the aforementioned, the default selected node of a line/slur could be the center node so that the motion of the mouse while clicked couldbe equivalent to how it is currently while jumping directly into edit mode automatically. It would also let the keyboard user move a line upon first selecting it without having to take the extra step of editing it first. It would make sense to do so, yet this would unfortunately make it a little less easy to extend a slur for instance upon entering into edit mode, which is usually the standard thing to be done, but not necessarily. Maybe when a slur is formed, keep the end node the default node, but when selecting one which exists already, the central node is default?

At any rate, hopefully this might push forward rethinking about facilitating note-entry and editing. It's not much, but it could speed up the process of editing/entry when one adds up all the time it takes to press Esc or getting into the editing area for lines/slurs etc, especially if the kinks were worked out so that no one complained about any changes (if that's possible). Ultimately, the desire is to make the least amount of action necessary for the most functional activities, and have it be something that doesn't trigger a mindset of "This shouldn't be like this".


Comments

Could you explain you see using 1)? It isn't clear to me what would be gained. Maybe a sample score and an example of an editing sequence that would get simpler?

2) and 3) seems straightforward enough.

4) I think maybe you underestimate how useful selecting can be for other purposes, like for instance, to change properties in Inspector or via shortcuts like "V", to delete (!), etc. I probably do any of these about 10 times more often than I actual use edit mode, in fact, I use edit mode on lines pretty rarely since I'm pretty good about adding them to the right range in the first place.

BTW, since these are pretty unrelated best to make them separate suggestions. Otherwise, it's harder to manage the issue. Like, if there were an issue for 2) independently, we could close it when that was implemented even 4) never happens.

In reply to by Marc Sabatella

Thanks for responding. Yeah. Didn't want to make separate ones just yet until maybe some discussion or further observations.

Regarding 1) Here's an example sequence of action:

suggestion_one.gif

a) A crescendo is placed while in note entry, which is allowed of course, but extending it at all is not allowed. In order to select the crescendo, the user has to b) get out of note entry, then c) "Select next element", then d)"Edit element", then d) do some extending, then e) hit escape shortcut, then f) "Select previous element" (or next element), and then g) press 'N' to get back into note entry.

The suggestion would allow for something like: while in note entry, a) press < to insert crescendo, b) "select next element" (and if suggestion 4 worked, it would automatically go into edit mode here to skip (c) -> c) ALT+SHIFT+E for edit mode , d) extend, and with the other suggestions, e) press 'N' to be back where the user left off jumping into select next element. Again if the suggestions were implemented in some appropriate manner, instead of (a-g), we'd have (a-d), three steps less.

Regarding 4: You're right, delete is very important, as with visibility, and of course inspector action is necessary. Yet the user already has access to the inspector while in edit mode so far as tested (except that the user has to use the mouse for such, as the tabbing will only cycle through the nodes.... hrm). And regarding delete and visibility, I don't see any reason why the user shouldn't be able to press 'v' while in edit mode and have it become invisible, or to press delete and have it delete the item and continue as usual . Practically speaking, a melding of selection and edit mode would be required to implement the suggestion, negating the need for having to "edit" an element, and allowing for all these actions already, just with nodes easily accessible via tabbing and their corresponding potential offsetting/anchoring.

I have another suggestion: if you ESCape when in the selection of a slur, please select automatically and systematically one of the slurred notes (the 1st one?)!
It's extremely frustrating to have to move to the mouse, carefully select the note then come back to the keyboard...

In reply to by bersyl91

Use [Alt+Left/Right] in the mean-time to continue without mouse usage.
Hopefully the escape behavior in the future becomes something like "select start anchor note" for anchored elements like slurs/texts/whatever.

Although, if this were implemented, what about the end anchor point for elements that have those? If one for instance uses a spanning line into the next system (crescendo for instance), and then escapes.... should the note selection be at its end anchor? Some how that 'feels' more appropriate than jumping back to the previous system, but maybe not? That will have to be dealt with.

Not sure exactly when you mean you are pressing Esc, but if you mean to leave edit mode, the slur should remain selected, and then Alt+Right/Left takes you to the next / previous note. If you mean you accidentally hit Esc one too man times and leave yourself with nothing selected, for 3.3 (to be released with the next few days I believe) hitting Alt+Right/Left will remember the last thing you had select and continue navigation from that point.