Feature #960
text-editor-like note selection
| Status: | In Progress | Start date: | 2014-05-22 | ||
|---|---|---|---|---|---|
| Priority: | Normal | Due date: | |||
| Assignee: |  Matthias Mauch | % Done: | 50% | ||
| Category: | - | ||||
| Target version: | - |
Description
I was wondering about a different way of time-scrolling in Tony: for some tasks such as note editing it would be nice if the control+L/R arrow key moved by one note, like in a text editor (sadly, on a Mac that's Alt+L/R arrow). Then Shift+Control+Arrow could be note selection, also like in a text editor. Or more generally, Shift+[any sort of L/R movement] could be selection. What do you think?
The reason is that this would make at least two common note-track editing actions (merge, delete) doable using the keyboard alone.
History
#1
Updated by Matthias Mauch almost 11 years ago
- % Done changed from 0 to 40
I did the "move by note" left/right.
Chris, could you please check whether the implementation is in the right place?
I'm also not so sure about the "slot" definition in the header file. Thanks!
#2
Updated by Matthias Mauch almost 11 years ago
- Status changed from New to In Progress
#3
Updated by Matthias Mauch over 10 years ago
- % Done changed from 40 to 50
I now pushed a version that does do note selection by keyboard using Alt+Shift+Left/Right.
Not sure this is a good solution, but it somewhat works... needs more looking into.
Chris: One thing that becomes obvious here, too, is that when selection is fast (as it is with keyboard interaction!) I think the automatic candidate analysis on selection slows things down too much. Maybe it'd be better to do only on demand after all.
#4
Updated by Matthias Mauch over 10 years ago
I now pushed a version that does do note selection by keyboard using Alt+Shift+Left/Right.
Sorry, this is Ctrl+Shift+Left/Right, actually.
#5
Updated by Chris Cannam over 10 years ago
Seems to work at first test (haven't looked at the code though!)
My first thought about the slowness is that it shouldn't be slow -- it shouldn't be waiting for any actual work to happen at this point. It's probably worth my putting a bit of effort into trying to understand why it's slow (and fixing that if possible) rather than disabling that feature just yet.
#6
Updated by Matthias Mauch over 10 years ago
My first thought about the slowness is that it shouldn't be slow -- it shouldn't be waiting for any actual work to happen at this point. It's probably worth my putting a bit of effort into trying to understand why it's slow (and fixing that if possible) rather than disabling that feature just yet.
Sounds good.
In fact, it should not just not be waiting for the re-analysis to finish; the re-analysis should be stopped when the selection is changing.
#7
Updated by Chris Cannam over 10 years ago
- Assignee changed from Matthias Mauch to Chris Cannam
Yep, working toward that.
You can see one change in the current 1277a5dd11f6 -- there is now a little Cancel button next to the progress bar on the view (as I think we talked about on the phone). That's very experimental, see if it works for you.
For my part I'm not so interested in cancelling the main analysis, but this is also the first part of automatically cancelling each re-analysis when a new one is invoked. I haven't actually got that behaviour wired through yet though, and I'm not going to manage to do that today.
#8
Updated by Matthias Mauch over 10 years ago
Exciting! Cancelling at the progress bar works for me.
#9
Updated by Chris Cannam over 10 years ago
- Assignee changed from Chris Cannam to Matthias Mauch
As of 6b57c58b88d2 each new selection step cancels the previous one, so selection should go quicker. Have a try and see how it looks to you -- there's potential to improve it further at some cost, but this is what you might call the low-hanging fruit.