Make extend selection commands (tracks/items/envelope points/MIDI notes) unselect when reversing direction

[Chessel85]

Hi. In the midi editor you can select contiguous notes with shift and right arrow.
If you select, say 5 notes, in this way then I would like to be able to unselect notes with shift left arrow. At the moment all the notes selected with shift right arrow remain selected even when you shift left arrow backwards. JUst want to be able to undo a selection if I have selected one note too many. And want the converse to work. If I first shift left to select notes, shift right should unselect. There is a workaround to go into noncontiguous note selection mode but my request would be more intuitive I believe. My guess is though, since this seems pretty obvious functionality, that it is pretty tricky otherwise it would have been done already. If that's the case then no worries and please close this request.

[jcsteh]

It is a bit tricky, but the main concern is that it's inconsistent with the rest of REAPER. For example, the builtin commands to select tracks, items and envelope points behave the same way: they never unselect. The action descriptions are pretty clear about this, though: they speak of selecting, not unselecting.

In the case of the MIDI editor, those actions are entirely implemented by OSARA, so we could theoretically do this. Even the track, item and envelope selection commands are overridden by OSARA these days. The question is whether we want to make things inconsistent with REAPER's builtin behaviour, especially because we can't override the action descriptions for some of the commands we override. That's probably a UX question for @ScottChesworth.

[ScottChesworth]

Am I correct in thinking that Reaper's current behaviour with the built-in actions not retracting selection is non-standard, @jcsteh? It feels that way considering this purely from a keyboard user perspective. If so, I can try opening dialog about a change of behaviour with Cockos, see if that leads anywhere.

[jcsteh]

It seems non-standard to me, yes. Curiously, though, Sonar had the same behaviour for certain selection actions if I remember correctly. That's not hugely relevant here, but it's an odd coincidence if nothing else.

Having said that, I just checked and it seems that REAPER doesn't provide commands for extending the selection to the next/previous item or envelope point, so OSARA added its own actions for those, and we can easily change the description for those. So the only builtin extend selection commands are for tracks, and OSARA overrides those completely anyway. To put it another way, OSARA is choosing to emulate the builtin behaviour, but it's completely controlled by OSARA, even when we override builtins. That leaves me with four questions:

1. Are there any other similar cases of selection I'm missing? I don't think so.
2. If not, can we live with OSARA's behaviour being different to the builtin behaviour, given that OSARA users won't ever encounter said behaviour? Probably yes. But:
3. We can't change the action descriptions for the extend track selection commands. Can we live with that being weird or should we create new OSARA actions? That would require a key map change and would break existing key maps.
4. If 2) is yes, is it really worth bothering Cockos with this, given that OSARA already controls this behaviour itself? The only advantage is that we wouldn't have to worry about inconsistency at all, but it's somewhat academic as I already described, and we probably have bigger fish to fry with Cockos.

[jcsteh]

Another thing to note is that REAPER doesn't have builtin non-contiguous selection, so if we really wanted to push this with Cockos, we'd probably have to push on that as well.

[ScottChesworth]

1. Are there any other similar cases of selection I'm missing? I don't think so.

I think that's all of 'em, yep.

2. If not, can we live with OSARA's behaviour being different to the builtin behaviour, given that OSARA users won't ever encounter said behaviour? Probably yes. But:

For me, when different also means closer to convension, I'm fine with different.

3. We can't change the action descriptions for the extend track selection commands. Can we live with that being weird or should we create new OSARA actions? That would require a key map change and would break existing key maps.

Probably not worth the extra keymap confusion at this point, we still don't have full adoption of the current map out in the wild yet. Perhaps we can replace the builtins with actions we have more control over next time there's a significant keymap release, but for now, I think the existing names are still describing the primary function of those actions adequately, even with this adjustment.

4. If 2) is yes, is it really worth bothering Cockos with this, given that OSARA already controls this behaviour itself? The only advantage is that we wouldn't have to worry about inconsistency at all, but it's somewhat academic as I already described, and we probably have bigger fish to fry with Cockos.

I'm yet to encounter a single part-time OSARA user, so agreed, that inconsistency probably isn't worth taking to the table right now.

[jcsteh]

Thanks. That's the UX decision made.

As for technical implementation, this is non-trivial, so I'm not going to get to it any time soon, but it's a valid feature request.

[jcsteh]

Removing assignee. There's no reason this specifically has to be done by me.

[ScottChesworth]

Pfft, well it was worth trying. :)

[MatejGolian]

@jcsteh, thanks for pointing me towards this issue. To offer my view point, it's true that the current behavior is nonstandard, however I do kinda like it, because it provides more flexibility, since it's possible to make note selections from both directions. Granted, it's not that common that one thinks of selecting notes from right to left - it's arguably much more common to think of notes as characters in a word processor, but still I don't think that we necessarily have to follow the same kind of logic here. My suggestion would be to add 2 new Osara actions for retracting selection - something like 'Move to next chord and retract selection' and 'Move to previous chord and retract selection'. Of course, the down sides here are that we'd need to accommodate 2 more keyboard shortcuts. Also, this approach might not be the most intuitive one in the world, but than again, depending on the assigned key combinations as well, this might turn out much less intimidating than it may sound right now.

[MatejGolian]

I just realized that my suggestion would be problematic in 2 cases:

1. When running the action to move to the previous chord and retract selection while focused on the leftmost selected event.
2. When running the action to move to the next chord and retract selection while focused on the rightmost selected event. The problem here is that in these cases there's nothing to retract and thus these actions wouldn't make much sense. So, even if my suggestion is totally impractical, I hope that it sparks some ideas...

[RDMurray]

I don't think the name of the commands matters that much; they change behaviour in non-contiguous selection mode anyway. As a random example from another program, VS code calls the action on Shift+RightArrow "cursor select right", even though it can also deselect.

I think it makes sense for it to work similar to file selection in Windows. Starting with one item selected, Control+Shift+rightArrow adds the next item to the selection, exactly as it is now. Control+shift+left deselects until there is only one item selected. The exact same thing happens in the opposite direction. Like file explorer selection but unlike text selection, you never end up with a situation where nothing is selected.

[RDMurray]

This gets a bit more complicated in the midi editor where it is two dimensional. Maybe shift+left/right should always select or deselect whole chords, including first selecting the current chord when selecting left or right. What do you thing?

[Chessel85]

Selecting whole chords makes sense to me.

From: RDMurray @.> Sent: 18 February 2022 18:20 To: jcsteh/osara @.> Cc: CastleStarter @.>; Author @.> Subject: Re: [jcsteh/osara] Make extend selection commands (tracks/items/envelope points/MIDI notes) unselect when reversing direction (#475)

This gets a bit more complicated in the midi editor where it is two dimensional. Maybe shift+left/right should always select or deselect whole chords, including first selecting the current chord when selecting left or right. What do you thing?

— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/475#issuecomment-1044960584 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AQOFDPRXQOX6SIDGQIPYKXTU32EUXANCNFSM4XPOLRTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>