Track Name Updates and Efficiency Improvements #26
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
More actions and fixes
Direct track selection in Mixer view w top row buttons
Mixer Mode Track Navigation
Direct API calls for track selection rather than Reaper actions to overcome 99 track limit
Track selection working Non existing tracks in last bank are now properly marked as not available
Bank selection
VU meter data format ok, but: - Need a better hook (update frequency) - VU meter updates not working properly. CMD_SEL_TRACK_PARAMS_CHANGED not fully understood yet
VU: - functionality is there! - some minor tweaks like scaling still open - code cleanup required
native conversion taken from Reaper SDK
- Calibration also valid for other keyboards than S Mk2?
-Meters working -Precise, non linear calibration for KK Mk2 Display Meters
Update niMidi.cpp
- Stub to isolate this pull request from fork master
Mute solo rec arm callbacks
- Track name changes get reflected via callback - Master track indicated in Mixer View (no mute or solo on Master) - Bank slect button light
Track names, master track, bank button lights
- implemented in plugin by supressing peaks because KK firmware does not use this command at all (yet?) - maybe some newer firmware version of KK will do so
Track(s) muted by solo implemented
…back Metronome Button Light Working
- future roadmap
* Use extended callback function to get event driven metronome update * Poll the metronome when project tab changes
Metronome button light via callback
Option currently implemented as const, i.e. needs to be chosen at compile time
Muted_By_Solo fixes and Generic Track Names
More button lights
Automation implemented
jcsteh
pushed a commit
that referenced
this pull request
Apr 25, 2022
4DEncoder Track Navigation LEDs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
More analysis on Reaper's callbacks shows inefficiencies as previously reported in forum. Rather than abandoning the callback architecture and reverting to a polling approach more state conditions are introduced to return immediately from callbacks when possible (i.e. change of parameters and relevance of parameters for current bank are checked). There is still a bit more cleanup to do. It also turned out that SetTrackTitle (which was introduced in one commit) is less efficient than simply updating the name on a selected track within SetSurfaceSelected (this works because a track needs to be selected to change the name). Overall, the callback architecture in Reaper leads to a MUCH more convoluted code than a simple polling approach and its efficiency is not as good as I was hoping initially. Unfortunately one has to actually test/debug Reaper's odd behavior for every individual callback and even in different circumstances. E.g. when selecting track 8, 16, 24 and so on with the mouse a huge cascade of callbacks is triggered but not so for other tracks. Also not if track selection happens via actions or Csurf_On.. methods. It even depends on which track was selected earlier if a long cascade is triggered or just one or two callbacks. Anyway, rather than changing horses I think it makes sense to stick to it - I figure the efficiency is still better than polling when appropriate filtering is used and thus worth the effort.