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

Track manager awareness not working #724

Closed
gacain95691 opened this issue Oct 26, 2022 · 7 comments
Closed

Track manager awareness not working #724

gacain95691 opened this issue Oct 26, 2022 · 7 comments
Labels
bug Something isn't working next

Comments

@gacain95691
Copy link

Using Reaper 6.69 (portable install), ReaLearn 2.14-0pre on Windows 10. Setting track volumes with BCR2000. Editing mapping target to "By TCP position". Making changes in track visibility with track manager is having no effect on the BCR. Additionally, these settings are not saving to the preset. If I save the preset, open a new instance, and select the preset, the mappings default back to "By position". I've tried this with instances in monitor fx, master track, and audio/midi tracks. Same issue. Many thanks for a fabulous tool!

@helgoboss helgoboss added bug Something isn't working next labels Oct 27, 2022
@helgoboss
Copy link
Owner

Thanks for reporting. Both issues reproduced(updates to track visibility not picked up immediately, "By position" track selectors not saved correctly). Fixing.

@helgoboss
Copy link
Owner

Picking up track visibility changes can be further improved by implementing the "polling on project state change count" mechanism suggested by Justin.

@helgoboss
Copy link
Owner

Polling on project state change count turns out to be not enough to pick up track visibility changes caused by ReaLearn itself (and possibly other scripts/extensions): When ReaLearn shows/hide tracks, it takes the most lightweight way possible, it just sets the track attribute and calls TrackList_AdjustWindows. This doesn't trigger a project state change and thus doesn't increase the state count.

Listening to "SetTrackListChange" also is not enough, it's not reliably fired when a track is shown/hidden.

Last resort: Poll the visibility of each track in the current project during each main loop cycle. Justin says that querying the visibility state of a track is very, very fast. I tested it and indeed it is fast enough to not matter at all. We iterate over all known tracks in the change detection middleware, so for enumerating all tracks, we don't even need to call REAPER. Performance check says it doesn't even take 2ms for 10,000 tracks in 90% of the cases. No brainer.

Now that we detect track visibility changes anyway as part of the normal change detection, we can also remove the "Use polling" checkbox from the "Track: Show/hide" target because it can react to the generated change events. This isn't a performance gain (because polling track visibility for a single target is super fast) but removes some user-facing complexity.

@helgoboss
Copy link
Owner

Will be available in 2.14.0-pre.8

@gacain95691
Copy link
Author

This is fabulous. Thank you. This thing is a game-changer.

@helgoboss
Copy link
Owner

Thanks for the donation, just saw it!

@gacain95691
Copy link
Author

Just had a chance to download this today. It is working perfectly on my system now. Many thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working next
Projects
None yet
Development

No branches or pull requests

2 participants