reaKontrol icon indicating copy to clipboard operation
reaKontrol copied to clipboard

Incremental Track Navigation

Open brummbrum opened this issue 6 years ago • 2 comments

Currently, reaKontrol uses Reaper's built in actions to navigate to the next/previous track when the 4D encoder is used.

reaKontrol treats the currently selected track as the focused track for KK instance focus. This makes sense. A user expects that incremental track navigation is relative to the currently focused = currently selected track.

However, Reaper's built in actions navigate relative to the last touched track, not the currently selected track. E.g. if a volume fader is changed on a non selected track (via the KK keyboard or the computer mouse) then the next/previous track will be relative to the track with the volume fader touched, not the currently selected track. This leads to unexpected jumps and also deteriorates the keyboard's mixer experience.

This issue can easily be reproduced even without reaKontrol active as it is a native Reaper behavior.

Suggested solution: Instead of using Reaper actions manage the last selected = focused track inside of reaKontrol and use API functions, namely GetSetMediaTrackInfo, to select next/previous track.

brummbrum avatar May 20 '19 03:05 brummbrum

Fixed the issue as per suggestion above. Tested, works fine now. Added corresponding pull request #9 https://github.com/jcsteh/reaKontrol/pull/9

brummbrum avatar May 20 '19 06:05 brummbrum

Ah. I didn't anticipate this.

The problem is that this breaks functionality for screen reader users (using OSARA), since track selection is only reported when these commands are used. There's some ongoing work to make OSARA report changes from surfaces, but it can't report track selection yet and this is going to be tricky to get right.

I haven't looked at your code yet, but I'm also not keen on having a separate concept of focus within ReaKontrol. That means that if a user does use the computer keyboard and then switches tracks with KK, the order will be out of sync.

One way to deal with this might be to fiddle with things so that the last touched track matches the currently selected track before using the commands. That'll be a bit tricky and ugly to implement, but it should work for all users nicely. I'll think on it.

jcsteh avatar May 27 '19 23:05 jcsteh