Arrow keys doesn't move object when several ones are selected
S5 - Suggestion
Select an object (e.g. a chord symbol, a text, ...) and use arrow keys ==> object is moved.
Select two objects (even of same type, e.g. 2 chord symbols), arrow keys don't work.
Arrow keys move the selected objects.
This is currently by design. it's not inconceivable that this could be changed, but there are complications to consider. Text elements and rests are the only elements that can be moved in this manner, everything else requires the element to be in Edit mode. And only one element can be in Edit mode at a time. But we could indeed try special casing text to allow multiple elements to be moved with cursor only. Meanwhile, though, the Inspector works.
In reply to This is currently by design… by Marc Sabatella
When editing the staff text properties, is it possible to make a vertical alignment change and tick a box to make the change to all selected text?
In reply to When editing the staff text… by Robert Ingham
You can select several items of the same type and move them all at the same time using the inspector (F8 toggles its display)
In reply to You can select several items… by mike320
aha, thank you, is it possible to get all selected items to snap to the same vertical alignment?
No, bit you can enable 'snap to grid' so you move with mouse only in steps or select several and set to the same offset
In reply to When editing the staff text… by Robert Ingham
Perhaps more to the point, though, if you have a bunch of items you want positioned similarly, that's what Text Styles are for. If you literally want all staff text elements positioned in this new way, just edit the Staff Text text style. If it's just a subset of the staff texts but all ones that are "conceptually" similar - like they are indicating annotations to the score, say - then you can create a custom text style and apply that.
In reply to Perhaps more to the point,… by Marc Sabatella
In my specific use case which leads to this thread, the "problem" was that almost all (but not all) fingerings in the measures under a repeat line were colliding with the repeat line.
After having selected the colliding fingerings (by ctrl+click) I was hoping to move them all by arrow key.
Would have been very convenient if it was allowed...
By "repeat line" do you mean a volta? Might be better to just move that instead. Anyhow, you can use the arrow key to move them at all once - just click in the appropriate field of the Inspector and use the arrow keys to change the value.
Also, instead of selecting the fingerings using ctrl+click, you can select the full measure(s) then right click on fingering use Select / All Similar Elements in Range Selection. Then Ctrl+click the ones you don't want to move, if any. This combined with the Inspector will be much more efficient than moving them individually.
In reply to By "repeat line" do you mean… by Marc Sabatella
Just tried ==> works like a charm. Thanks Marc!
In reply to Just tried ==> works like a… by frfancha
Oops I spoke too quick:
There is a big difference (apparantly, or am I wrong??) to the inspector method compared to what would be possible by arrow keys:
using the inspector forces offset of all selected elements to become equal ...
Using the arrow key on the multi selection would add or substract the same amount to the possibly different offset to begin with, that's something different.
Good point. In that case, you'll need t use the mouse. Hold Ctrl when you start the drag to keep all elements selected, then release it so you aren't constrained to horizontal motion only.
In reply to Good point. In that case,… by Marc Sabatella
Thanks for the tip with the mouse, seems to be the solution, but in fact no: as soon as I begin to drag, the offsets of all selected elements are reset to the same values as the offsets of the element on which the mouse is.
At least it happens like that for chords in 2.1.
Just after very small drag of chord B:
Ah, yes, true, sorry for misleading you. One at a time seems the only way then if you need to preserve the relative manual adjustments already made.
In reply to Ah, yes, true, sorry for… by Marc Sabatella
Note that I see that as a bug: dragging with the mouse several selected objects has no reason to first align offsets
See #9347: ctrl-drag a group of objects should not first reset positions. I'm guessing there is a reason for this, as I noted when I submitted this years ago. But that doesn't mean it can't be revisited.
In reply to See #9347: ctrl-drag a group… by Marc Sabatella
I fully agree with your text of some years ago: 'ctrl-drag a group of objects should not first reset positions'
Perhaps it is not a "bug" in the sense that the code was explicitely written to do that, but anyway it is clearly a non-sense.
In reply to Hi Marc,… by frfancha
In Version 3, dragging with the mouse several selected chords doesn't work at all for me. The score is moved on screen instead.
And moving several selected elements such as chords by keyboard is still impossible, while moving them by keyboard one by one works like a charm. Frustrating.
I think the reasoning hasn't changed since 2.0 (and the issue you link to predates that release by several years): now that we have the Inspector that shows offset values numerically, not resetting positions would be problematic in that it would mean the Inspector would be lying no matter what it shwoed, and in case, the Inspector remains the better way to do this sort of thing.
In reply to I think the reasoning hasn't… by Marc Sabatella
Allowing arrows to move multiple items would make it much easier to move like items up 1 space for example, while their offsets may vary from one item to another. We basically allow this for multiple notes (though the pitch changes with the location), why not for multiple text items? Pressing up arrow subtracts 1 from the x offset, ctrl+right arrow add 0.1 to the y offset and so forth.
The complication I mentioned is that the offsets for the markings would be different, so the Inspector would be lying. This isn't an issue for notes, because they would all have the same offset. That is, all notes start with offset off, so there is nothing to reset when moving them. Plus you aren't actually changing the offset. If the Inspector had a property "pitch" then we'd have the same issue the Inspector showing just one pitch even though they differ. It's not an unsolvable problem, but it is something that would need to be dealt with.
BTW, not sure why you'd be trying to drag notes, it's always "worked" but never been a good way of actually accomplishing anything that isn't better done through other means.
I don't really get why you mention the inspector here.
Selecting one chord and moving it by arrow keys doesn't use the inspector, we just ask to be able to do the same with several selected chords.
I was talking about the original topic, which wasn't about notes but about text and other elements. The Inspector is relevant to that, and I was also explaining why it is not relevant to using dragging as an alternate method of transposing notes.
In reply to I was talking about the… by Marc Sabatella
As soon as you select two text items with different offsets, the inspector lies anyway. The fields that are different would ideally be blank to show this is the case, but an arbitrary item's offset is fine with me, I've learned to ignore it. So, the lying inspector is no excuse to say this isn't possible.
As I said, it's not unsolvable, just something to consider, and one reason why it hasn't been done already. The lying done on initial selection is handled differently in the code form the lying that would need to be done if we needed to support dragging this way,
Thou shalt not lie to an inspector
In reply to Thou shalt not lie to an… by Jojo-Schmitz
In other software such as MS-PowerPoint, when you open an "inspector" with several elements selected, the properties with the same value for all selected elements render a normal UI, the properties with different values for the group of selected elements render an empty UI to show that a "common" value doesn't exist.
See here three elements with same horizontal position, but different vertical position.
And moving the three elements with arrow keys work perfectly, updating the horizontal position in "inspector" moving left and right, keeping the vertical position empty in inspector moving up and down.
That's what I suggested as what MuseScore would ideally do.
Encountered this bug today in MuseScore 3.5.2, when attempting to vertically reposition several chord symbols on the same line.
It is much older though, at least since 2.1, probably ever since
Meanwhile, if the goal was to algin the chord symbols, MuseScore can do that automatically throughout the score if you set a maximum shift amount in Format / Style / Chord Symbols. Or to do it for just selected chords, you can set their offset in the Inspector.