Producing a discontinuous selection is difficult
Consider the situation where I have a 4/4 treble-clef bar with eight quavers in voice 2, underlying a complicated melody in voice 1. I want to delete the quavers but leave the melody behind.
As per the manual, my primary options for selecting multiple elements are Shift+drag-LMB, or selecting the first element and then using Shift-and-arrow-keys to expand the selection to multiple elements.
In both cases, this currently produces a range selection, which does not discriminate between notes within a chord or voices within a stave - it simply selects a time-range across the entire stave. In this example, if I were to attempt to select only the quavers in voice 2, then the melody in voice 1 would also be selected.
I believe the prescribed way to deal with this is to either use selection filters or use the "Context menu/Select/All Similar Elements in Range Selection" option, but it would be much more convenient if we could handle this situation using only the mouse and keyboard on the canvas. Currently, my only option in this case would be to hold down the Ctrl key and individually click on all eight quavers!
Suggested solutions:
-
When a discontinuous selection is active, it's currently possible to deselect individual elements using Ctrl+LMB. However, when a range selection is active, Ctrl+LMB on a selected item has no effect, and Ctrl+LMB on a non-selected item seems to be bugged - it dismisses the range selection without selecting the clicked item. I suggest that Ctrl+LMB should always select/deselect the clicked item. This will require Ctrl+LMB to sometimes convert a range selection into a discontinuous selection.
-
Drag selections (shift+LMB-drag) will currently select additional elements which lie outside of the drag rectangle, so that the resulting selection is always a range selection. I suggest that drag selections should not select any notes or rests other than those which are strictly within the drag rectangle. This will require drag selections to sometimes produce a discontinuous selection, rather than a range selection.
Comments
Can you attach an actual score and describe exactly what you're trying to select, and how your proposal improves over the existing facilities for that specific case? I'm having trouble understanding the perceived issue. To me this is precisely what the selection filter is designed to solve, simply and elegantly.
FWIW, drag already creates list selections, if not notes or rests are in the region. But if you include notes or rests, the natural assumption is that the user wants to select a range, as these are normally much more useful. So I think most users would be negatively impacted by eliminating that feature.
Hi Marc,
My example score is attached. The task is to perform an operation on all of the Voice 2 notes (such as deleting them, transposing them downwards by a third, or cutting them so that they can be pasted into a different stave) without having to re-enter any of the Voice 1 notes. Please pretend that you're a novice user who doesn't know about selection filters.
In reality, I agree that the "selection filters" panel is probably the best tool that MuseScore has to offer in this case. However, it's difficult for new users to discover, and I frankly find it a bit awkward to use. The shortcut key is F6 (which can be tricky to press on a laptop), the panel takes up a lot of screen real estate when it's activated, the checkboxes are small and difficult to click, the sheer number of checkboxes can be disorientating, and it affects all of your future selections if you forget to reset it (even if the panel is no longer on-screen!). It's also a bit inconsistent: it requires positive reasoning ("I only want to select these things") if you're about to make a new selection, but negative reasoning ("I only want to deselect these things") when you're modifying an existing selection.
I suspect that if a novice user was given the task I've described above, they'd start by trying two different things:
Using a drag-selection to select and manipulate all of the Voice 2 notes in the first system, then doing the same thing in the second system.
Creating a range-selection over the entire score, then individually deselecting each of the Voice 1 notes.
Currently, both of those approaches would unexpectedly fail, and the user's next steps wouldn't be obvious. If my suggestions were implemented, then both approaches would work as expected.
Even for a more experienced user, I think that when you're only manipulating one voice at a time, a more conservative drag-select would be a very useful tool. We already have an easy way to produce a range selection (shift-clicking), so I'm not sure that we necessarily need drag-selection to aggressively upgrade list selections into range selections... if the user receives a list selection when they expected a range selection, then they have an easy way to fix it!
Note that in my proposal, drag-selection would still usually produce a range selection. It would only produce a list selection when producing a range selection would require the selection of additional notes/rests which lie outside of the drag rectangle.
I guess to me when a powerful feature is there to be read about in the Handbook, adding yet another less powerful feature that the user is no more likely to discover doesn't seem that valuable. The number of cases where it happens to be possible to do a drag selection and catch one voice without catching anything else is far smaller than the number of case where a user actually wants to create a range selection but doesn't quite get everything in. So I think this will seem like a step backwards. But I'll leave it open for further consideration by anyone else.
Meanwhile, if there are ergonomic issues with the selection filter, I think it better to just address those head on.
Seems fair - now that I give it more thought, it's plausible that a drag-selection might miss, e.g., a note which is several ledger lines above/below the stave.
Any opinion on my other suggestion: that Ctrl-clicking an element while a range selection is active should select/deselect that element, by converting the range selection into a list selection? It seems like an obvious extension to the existing Ctrl-click functionality, and unlike my other suggestion, it wouldn't require any potentially-useful functionality to be deleted.
That has been proposed before, and you're right, it's probably harmless. I suspect it still won't help people that much as the functionality you lose in converting range to list selection is significant, and also, you have consider things like, would the barlines, dynamics, clefs, and other elements be included in the list, etc, and the answer is probably sometimes you might want that and others times not depending why you are trying this. But again, probably harmless.
Harmless indeed, and I've gone ahead and produced an implementation of that portion of the suggestion: ctrl+click with a range selection will first convert the range to a list then process the ctrl+click normally. Seems like it could potentially sometimes be useful although I don't really have a specific use case in mind.
See https://github.com/musescore/MuseScore/pull/6139. I think this addresses what "needs" to be here. I still have reservations about the rest of the suggestion, since implementing it would adversely affect a feature I think many rely on.
Fixed in branch 3.x, commit 5fd1855c3f
_fix #297423: allow ctrl+click to modify range selection
This partially resolves https://musescore.org/en/node/297423,
and address a common request:
the ability to add or subtract an element from a range selection.
We currently allow building list selections with ctrl+click,
but ctrl+click does nothing interesting with a range selected.
While some might want a new "magic" range selection
that has random elements added or removed from it,
that is beyond the scope of what I am doing here.
This change simply converts the range to a list
before processing the ctrl+click.
So the end result is a list selection that consists of
everything that was formerly in the range selection,
plus or minus what you just ctrl+clicked._
Fixed in branch 3.x, commit a99db6ef2f
_Merge pull request #6139 from MarcSabatella/297423-ctrl-range
fix #297423: allow ctrl+click to modify range selection_
Automatically closed -- issue fixed for 2 weeks with no activity.