Track Follows Mixer View Request

[AlbertoV5]

Reaper has "DEVICE_TRACK_BANK_FOLLOWS" which allows banks to follow "DEVICE" and "MIXER". Right now an implementation for track colors using both Realearn and Reaper's base OSC is to store the bank size and current bank as parameters, say p1 and p2. Then I can get the values of tracks (1, bank_size) dynamically with something like (p1 p2 10000) + track_n, etc.

The issue is that Realearn doesn't have a Track Bank/Track Selection Follows Mixer view option. Which makes it so the result of the implementation gets the colors of tracks 0 to 7 even if say tracks 3, 4, 5 are not in the mixer view. The ideal result would be getting the colors for tracks 0, 1, 2, 6, 7, 8, 9, 10 (assuming 7,8,9,10 are in the mixer view).

This is just an example but I hope it makes sense and that it can be considered as the alternative workflow is the classic buses and sub buses at the top always and the routing becomes spaghetti.

Thanks.

[helgoboss]

Can you describe that option a bit more in detail?

[AlbertoV5]

Yes sorry I read that again and it's not clear.

It's about OSC. Reaper has the option to allow the controller to follow the MCP/Mixer view. So whenever tracks 2-5 are hidden from the Mixer view, then the controller sees the order as Track 1, Track 6, Track 7, Track 8, etc. The setting looks like this:

DEVICE_TRACK_BANK_FOLLOWS determines whether the selected track bank in the device changes only when the device changes it, or if it follows the REAPER mixer view. Allowed values: DEVICE, MIXER

Having said that, I am using the new and super nice Realearn feature to send Track Color as a string. And I am telling my Device to change Reaper Banks and Realearn Parameters at the same time, so syncing Reaper, the Device, and Realearn to be on the same "track bank" works fine so far. This works perfectly if the setting DEVICE_TRACK_BANK_FOLLOWS is set to DEVICE as all tracks are shown on the Device regardless if they are visible on the MCP/Mixer view.

The issue comes when trying to work with DEVICE_TRACK_BANK_FOLLOWS set to MIXER. As Realearn respects the track number even if it's not visible on the Mixer view. So, going to the same example, whenever I hide tracks 2-5, the Device follows Tracks 1, 5, 6, 7, 8, 9, 10, 11 but they get the colors of Tracks 1, 2, 3, 4, 5, 6, 7, 8. That's the easiest case but it applies to other cases that use Dynamic to follow tracks depending on the context (track banks, selected track, etc).

Here are some gifs as example:

I mentioned a workflow alternative (using DEVICE_TRACK_BANK_FOLLOWS DEVICE) which is like a Pro Tools rig would work so you jump around different Screensets and you have fixed banks of 8 or 16 and you fill your template with a bunch of tracks to account for those banks, etc. Reaper's DEVICE_TRACK_BANK_FOLLOWS MIXER needs the Mixer window to be open so that's a small drawback but the FOLLOWS MIXER workflow IMHO skips the need for fixed-size banks and templates and makes it easier to mix projects of different sizes.

So anyway, I don't think is a big issue, it seems like it just affects the Dynamic cases that want to follow the MCP/Mixer view.

Hope it made sense, thanks.

[helgoboss]

Ah okay. So you do the control direction via REAPER OSC and the feedback direction via ReaLearn OSC? If so, why mix it? Maybe I could extend ReaLearn to implement this "follows mixer" logic as well (I guess that's what it boils down to anyway) and then you could use ReaLearn for the control direction as well ... which would ultimately probably be more simple than mixing these different solutions?

[AlbertoV5]

Hi. Yes, I combine them for now as they complement each other well. Plus I prefer Realearn over CSI. I'll eventually move everything to Realearn.

In this case Realearn only sends the Track Color feedback. On other pages it runs actions and FxParams dynamically, etc. This is the template just as a reference: https://github.com/AlbertoV5/TouchOSC-Betov5/tree/Feature-Desk3

So yes it's all just to say that it would be nice to have an option on Realearn as a little checkbox that says Track Follows MCP and/or Track Follows TCP.

Thanks.

[helgoboss]

Adding new track selectors:

• By TCP position
• By MCP position
• Dynamic (TCP)
• Dynamic (MCP)

Text feedback for these targets using the usual placeholders will always count all tracks. Existing track index variables in dynamic expressions, too.

Adding "Track indexing policy" dropdown to target "Project: Navigate within tracks". Control, numeric feedback and text feedback will respect the setting.

[helgoboss]

Design decision: The reason for introducing new track selectors instead of adding an indexing policy dropdown (or checkboxes) for most track targets is that this makes it more clear and explicit that it affects the track resolve step only (the process of finding the desired track). It doesn't affect things like track exclusivity or text feedback placeholders. Rightfully so because one might want to follow MCP visibility when resolving the track but ignore MCP visibility when printing the track position on a display.

[helgoboss]

The target "Project: Navigate within tracks" still always includes the master track, no matter its TCP/MCP visibility. In future, we can implement this as part of #240.

[helgoboss]

In order to support scenarios in which the control surface does track banking via track selection (first fader controls selected track, second fader selected track + 1) while still following visibility, we need to introduce dynamic variables selected_track_tcp_index and selected_track_mcp_index. For the sake of completeness, also the array variant selected_track_mcp_indexes and so on.

[helgoboss]

In order to not mix up MCP and TCP selection, we should probably allow them to exist as 2 separate selections. The current selected track e.g. in terms of MCP would then only look for selections among the MCP-visible tracks, giving precedence to tracks that are only visible in MCP.

Update: Turns out this is nice if the set of tracks that's visible in MCP and the set that's visible in TCP is disjunct. Then we can navigate in each set independently. But it's confusing if the sets overlap. So this behavior should be optional.