Quote:
Originally Posted by schwa
You want the old behavior back, where the DEVICE_PREV_TRACK and DEVICE_NEXT_TRACK actions cause the track selection in REAPER to change? I suppose we can add an option for that.
|
Yes, it should be an option. The behavior was awesome in the simple case - you're controlling REAPER from a single device, as a single user, but it was undefined and uncontrollable, so undesirable effects in corner cases could not be prevented.
It should probably default to off, while we think of something for those corner cases (Should it be exclusive, i.e. for one device at one time only? Who decides? Warn the user when another device is also setting the track selection in REAPER? Can the REAPER user override exclusive control from devices? Etc.). Preferably after getting some input from different users that have had some practical experience with scenario's such as one person using a computer running REAPER (i.e. recording engineer), who is recording a couple of musicians that are all using remote controllers controlling some aspects of REAPER as well. I can do some testing with multiple devices, but e.g. recording sessions with multiple persons operating remote control devices are definitely not my daily workflow, but I can easily imagine they will become important to many REAPER users.
Since it could easily be confused for the feature where the device track selection follows the track selection in REAPER (i.e. the other way around), we should pick a really unambiguous name.
---
I also (still) think it would be useful to be able to have TRACK_NUMBER (and the other *_NUMBER patterns) both send and receive (to skip directly to a non-adjacent track, etc.) integer values. It looks quite weird to use a string for something that can only take an integer number as a value, so I'm also wondering what explains this particular design choice?