Slurs: Behavior (a few points)

• Jan 11, 2020 - 01:04

I'd like for slurs to be able to do cross-staffing within multi-staved instruments (piano, etc.) through the keyboard (like with notes doing cross-staff action) using the same [move up/down] commands. In thinking about this, I noticed a few peculiarities about the way slurs operate:

1) Slurs can be extended to rests while using [Shift + Left/Right] keyboard command. However, using the mouse, the node won't take to a rest! This should be consolidated so that the user can also drag a slur's end-node to a rest with the mouse, just like it is allowed with the keyboard. Sure, most of the time slurs don't need to go to a rest. As a matter of fact, I find slurs going to rests to be slightly absurd, and the only thing I can really imagine doing this for is like with "Let Vibrate" slurs. But, why should the keyboard be allowed to do this but then not allow the mouse to do it? And not just visually, but actually get the node to snap so that if any layout changes occur, they don't mess up the positioning look.

2) While being dragged, slurs "snap" to the top or bottom (depending on stem direction) of chords, and not truly to individual note-heads. Sure, it at first looks like they snap to a notehead, but what happens is that visually a note will get highlighted while dragging a node to it, but the result is that the node ends up on the top/bottom of the chord structure. For instance, if there's a chord with 4 notes in it, dragging a slur's end node to one of the notes will highlight that particular note, yet the result gives the node position to no particular note-head but to the entire chordal structure. This is no problem, but here is the point: why then should the user have to drag the node to an individual note-head? I'm not saying it's wrong, but in my opinion, the user should also be able to drag a slur's end node to a chord area, and the "magnetic" node shift would still occur instead of requiring the user to explicitly touch a notehead. This is just opinion, and maybe there's a good reason for not allowing this, but it would allow for a little leeway in using the mouse for slur placement

3) When thinking about slurs being able to "cross-staff" like the user can do with the mouse (but not the keyboard), if attempting for example to move from a bottom staff to a top staff that doesn't have the same amount of active chord segments: like, say the top staff has one quarter note and then three quarter rests, but the user is in the bottom staff at the end of the same measure on the fourth beat with the slur node there. If the user were to "move the slur up", where should it go? The first note itself on beat one? Or that last quarter rest on beat 4? I mainly lean toward thinking it should go to whatever is closest beat-wise, be it a rest or a note/chord, and not expect it to attach to only notes/chords. If there weren't any rests or notes at that particular beat from which the user started, have the node fall backwards to the previous note/chord or rest, wherever it is.

Hopefully this thread, if anyone has any observations about these, can be a place to share some insight or opinions, or whatever. And maybe this will lead someone to implement allowing the mouse to connect slurs to rests while dragging, and of course, cross-staff slurring with the keyboard.


Comments

1) eventually we hope to allow all lines to be properly extended by dragging, so yeah, this would get covered as part of that

2) the drag & drop code needs to have an element to drop to, this isn't specific to slurs or notes or chords. while it's theoretically possible to broaden drop zones around elements, the danger is in it becoming harder to select a specific element accurately in a crowded environment

3) would have to play with a prototype implementation and some real world scores to get any good sense of that

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