Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request to modify selection behavior #1085

Open
reaperaccessible opened this issue May 22, 2024 · 6 comments
Open

Request to modify selection behavior #1085

reaperaccessible opened this issue May 22, 2024 · 6 comments
Assignees

Comments

@reaperaccessible
Copy link

I don't know if the problem should be reported to Cockos or this could be modified in OSARA.
Here are the steps to create the behavior on your side.
I create 10 tracks in an empty project but the behavior is the same regardless of the number of tracks or items.
I select track 2, I press Shift+Down Arrow until the 10th track.
So, tracks 2 to 10 are selected.
But ultimately I don't want to select track 10 so I leave Shift pressed and press Up Arrow.
If I delete the selected tracks, track 10 will be deleted even though it was deselected.
It's the same behavior the other way around.
It's the same behavior with items.
Would it be possible to modify this behavior?
Thanks.

@ScottChesworth
Copy link
Collaborator

Technically possible, but it would be a lot of reworking. For now, hit Shift+Space on the track or item you want to remove from selection.

@jcsteh
Copy link
Owner

jcsteh commented May 22, 2024

The key point is that in REAPER, contrary to standard convention, shift+anything never deselects. This is clear from the action names. For example, in "Track: Go to previous track (leaving other tracks selected)", notice that there's no mention of deselecting, only selecting. That doesn't change the fact that it goes against standard convention, but it has been thus for a very long time now and changing that would likely break a great deal of muscle memory for folks that have used REAPER for a long time. I think this is one of those situations which is definitely not ideal, but which pragmatism requires us to leave well alone.

As a side note, I believe Sonar broke convention in exactly the same way. This makes me wonder what other DAWs do with such commands, but that's entirely academic really.

@jcsteh jcsteh closed this as not planned Won't fix, can't repro, duplicate, stale May 22, 2024
@jcsteh
Copy link
Owner

jcsteh commented May 22, 2024

@ScottChesworth, I guess the question of whether it would really break muscle memory that much is maybe less clear than I initially thought. If you don't think it would hurt users, we could leave this open to eventually do one of two things:

  1. Change this in OSARA only, accepting that it would deviate from REAPER behaviour without OSARA.
  2. Convince Cockos to change REAPER and then change OSARA as well. Because of how this stuff works in OSARA, we wouldn't get this behaviour for free even if Cockos change it, so convincing Cockos only serves to make things consistent.

@ScottChesworth
Copy link
Collaborator

I've been asked about this often enough that I think changing to more standard behaviour would be a good thing, particularly for new users. However, we both prefer OSARA not to deviate too far from REAPER's intended behaviour.
I'll reopen for now, lemme have a chat about it with Justin, let's see what the likelihood is of Cockos changing their keyboard UX.

@reaperaccessible
Copy link
Author

I think that users would not have a problem adapting to this change, on the contrary, very often we delete items or tracks by mistake caused by the fact that this behavior is not the one who is known to everyone.
This requires to undo, deselecting what we don't want to delete, and finally deleting.
In the case of a track with several FX, this may take time.
The way to select tracks or items in Reaper is a lot like selecting text.
How to select and deselect text is known to all users of screen reding software.
Thanks to look into changing this behavior, but if it's too complicated or impossible, it doesn't matter.

@tbdalgaard
Copy link

I believe it is important that osara follows as much as the Reaper standard behaviour as possible. If I work with a sighted Reaper user I much can discuss the workflows from a Reaper standard perspective, but if osara at some point will change so it deviates quite much from Reaper, that might make some gabs between users. I really enjoy that I have the same language for using Reaper and that a sighted user can see how I can work with Reaper, if we need to. I know osara has some nice tricks, like the move relative to the edit cursor, but that is an option, and that makes a huge diference for me. So if this changes within Reaper itself, I would be more positive.

Moving away from standards and how the main developers of Reaper have decided to implement the core concepts, might result in some situations where a non osara user might have a hard time working with a osara user, because they expect too different workflows, since osara modifies some of the standard behaviour in Reaper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants