Stems separate from note heads when dragging notes
Select multiple notes with the mouse to click and drag the whole group, say up or down an octave. The stems of the notes are likely to go off in an entirely different direction and end up quite separate from the note heads.
I apologize in advance if somebody else has submitted the issue already—it seems unlikely I'm the first one to report it—but I couldn't seem to find it on the site, so here I am.
Comments
FWIW, I wouldn't be too surprised this hasn't been reported. Drag of notes is not a common operation. The more usual way to transpose notes - which I assume was the goal or your drag operation - is with the arrow keys.
If it's the same issue, it was once reported: #9920: Stem and beam detaches from note head
Maybe it has returned?
And to change by an octave ctrl + up/down key , is MUCH precise (and faster as well)
Fixed in 44db952582
FWIW, the earlier issue specicially had to do with beams only, according to Werner's comment. This one affected unbeamed notes as well.
It's actually special case. When you drag things, normally it affects only their physical position on the page, not their "meaning". That's why, for instance, you aren't supposed to drag to extend voltas, ottavas, or other lines; you need to use the Shift+arrow keys to extend lines "semantically". But there is special handling for notes so that when dragging them, it *does* cause them to actually change meaning - they change in pitch just as if you had moved them normally using the arrow keys. That's all well and good, but a selection *also* includes stems, and those were being dragged "physically". So when the notes change meaning, the stems are automatically redrawn to their proper position, but you are *also* dragging the stems, so MuseScore was dutifully moving them physically on the page.
Werner's fix makes it so stems and hooks are not actually included in the drag - so the automatic recalculation of their location
It's *still* going to be the case, however, that dragging a selection of notes vertically is not a good substitute for the arrow keys. Consider, what if there were articulation markings in the selection, or lyrics, or chord symbols, etc. The chord symbols and lyrics will get dragged too, but they shouldn't be - their vertical position isn't supposed to depend on the position of notes. And articulations will show the same issue as with stems before the fix - if a note has a staccato dot, you are dragging that physically, but that offset will be applied to the new logical position of the note, so it will be too far away in the same way the stems were. Except for articulations like articulations like fermatas that were supposed to stay outside the staff; these will move like lyrics and chord symbols (and it will be just as inappropriate).
Really, the whole idea of dragging a selection of notes vertically is just flawed. We'd have to special case every type of marking to decide which ones should be moved and which should not to try to "do what I mean not what I say". I am actually inclined to suggest we simply disable dragging of notes, or at least, maybe disable it for anything but a single selection.
Or, perhaps, make it so if there is a range selection, we do the transposition *only* and not actually drag any other element types.
Your last suggestion sounds reasonable, though the fix is also great—thanks, Mr. Schweer. And thank you for the tip, Lamardelmy.
Please don't disable dragging of notes. I disagree that "the whole idea of dragging a selection of notes vertically is just flawed." It's actually quite a lot faster than repeatedly hitting the arrow key, because not only is there time wasted at each half-step while MuseScore plays the note, but there's also a definite delay every time while MuseScore just processes the action.
Hmm, I guess that's technically true if you are working on a score large enough to notice, but then, *all* edit operations will be equally slow.
I drag notes too for the same reason (quicker than keyboard).
Actually, no, you're right. Some ornaments still behave the way the stems used to, even after the fix. I think "make it so if there is a range selection, we do the transposition *only* and not actually drag any other element types" makes the most sense.
Probably makes sense to file a new issue. Wouldn't hurt to list which elements are problems as it *might* come down to needing to special case them one by one. I'm hoping not, though. I'm hoping it's just a question of doing the transposition and nothing else.
Automatically closed -- issue fixed for 2 weeks with no activity.