Wrong track state sent to control surface for action or API-based track selection

[tack]

I have a Faderport control surface setup, and when I click tracks with the mouse, the control surface receives the newly selected track's current volume and all is well.

But if I jump to a track using an action or API call, such as Go to next track (40285) or Go to previous track (40286), it continues to send the volume of the last mouse-selected track.

Perhaps the intended behavior is such that only the last touched track will get sent to the Faderport? But if that's the case, shouldn't the Set first selected track as last touched track (40914) cause the Faderport to receive the newly selected track's volume?

I thought perhaps I could hack my way around this with Reascript but I confess the csurf APIs are completely impenetrable to me.

If this isn't a bug, I'd very much appreciate some cluebatting. (Edit: I'm now quite sure this is a bug.)

Thanks!

[tack]

I've not had any luck finding a workaround here with the FaderPort.

It's really quite broken. I know a lot of people here use control surfaces with motorized faders, has no one run into a problem with using scripts to programmatically change track selection, or actions that do the same?

Once you select a track programmatically, not only does the control surface not receive the correct volume (or other state such as mute and solo) of the newly selected track, but adjusting the selected track in the MCP doesn't send the new volume to the control surface either.

For example:

local track = reaper.GetTrack(0, 0)
reaper.SetOnlyTrackSelected(track)
-- Track: Set first selected track as last touched track.
reaper.Main_OnCommandEx(40914, 0, 0)
reaper.SetMixerScroll(track)

This won't send the first track's state to the control surface.

Another blind attempt to workaround this was:

reaper.CSurf_ResetAllCachedVolPanStates()
reaper.TrackList_UpdateAllExternalSurfaces()

Alas no effect.

When it comes to programmatically focusing a track in a control surface compatible way, I've completely hit a brick wall. For me, the control surface only ever updates when I use the mouse and manually click on a track. I've not found any other way that updates the control surface.

Any help would be very much appreciated.

[nofish]

Hi,

I'll say in advance it's not much I have to offer...

Originally Posted by tack

local track = reaper.GetTrack(0, 0)
reaper.SetOnlyTrackSelected(track)
-- Track: Set first selected track as last touched track.
reaper.Main_OnCommandEx(40914, 0, 0)
reaper.SetMixerScroll(track)

This won't send the first track's state to the control surface.

I just tried this using Klinke's MCU extension + BCR2000 as Mackie Control emulation and it does work fine here. When I'm on say track 9 (the MCU works in 'pages' of 8 tracks) and I run this script the BCR correctly switches back to Tracks 1 - 8.

As said, not much to help, but maybe it could give some sort of clue anyway.

edit:
Now something more interesting probably...

I just tried the same with Reaper's native Mackie surface mode and it's NOT working, same as you describe.
So I think I can confirm. Maybe Klinke has built a special mechanism into his extensions (it has a mode called 'follow Reaper' which I use), I don't know.

[tack]

Originally Posted by nofish

I just tried this using Klinke's MCU extension + BCR2000 as Mackie Control emulation and it does work fine here. When I'm on say track 9 (the MCU works in 'pages' of 8 tracks) and I run this script the BCR correctly switches back to Tracks 1 - 8.

Thanks nofish, I appreciate your testing.

I wonder if it's something about Reaper's Faderport control surface mode. Does Reaper behave natively (i.e. without Klinke's MCU extension), at least with respect to this problem?

[tack]

Another test: I put my iCON Platform M in Mackie mode, and added it as a Mackie Control Extended control surface.

But even here, with an out-of-the-box configuration, it doesn't work like I expect: clicking tracks with the mouse button changes the fader groups, but selecting the tracks with the API or actions (e.g. "Track: go to next track" action) doesn't change the fader groups. It DOES however update the indication as to which track is selected on the control surface.

So this behaviour is consistent with what I'm seeing with the FaderPort mode as well.

I guess if this isn't a bug, then my question is how can one force whatever magic happens when a track is clicked on by the mouse from an API call or action.

[tack]

Continued to experiment with several other actions / APIs to no avail.

Of all the reaper bugs/limitations I've encountered, I have to admit this one is the most frustrating to date. Usually I can find a scriptable workaround, or change my workflow slightly, but this one is obstinate and seriously limits the usefulness of my control surface.

[Klinke]

Have you tried SendMessage(g_hwnd,WM_COMMAND,ID_TOUCH_SELECTED_TR ACK,0);
after you selected a new track? I have an option that enable this behaviour in my control surface, and this option is enabled by default. For selecting a track I use CSurf_OnSelectedChange, maybe this is also important.

To see the context in my implementation, you can take a look at the MultiTrackMode::buttonSelect method, starting at line 330:

https://bitbucket.org/Klinkenstecker...iTrackMode.cpp

[tack]

Originally Posted by Klinke

Have you tried SendMessage(g_hwnd,WM_COMMAND,ID_TOUCH_SELECTED_TR ACK,0);

I haven't, no. Do you know if that's possible from Lua? That's what I had meant by "API-based."

Although ID_TOUCH_SELECTED_TRACK sounds suspiciously like action 40914 (Track: Set first selected track as last touched track) which doesn't help. Also I suppose even if SendMessage were accessible from Lua it wouldn't be compatible with OS X (though as a Windows user I'm prepared to live with that ).

I tried CSurf_OnSelectedChange() like so:

reaper.CSurf_OnSelectedChange(current_track, -1) -- also tried 0
reaper.SetOnlyTrackSelected(new_track)
reaper.CSurf_OnSelectedChange(new_track, 1)
reaper.CSurf_ResetAllCachedVolPanStates()
reaper.TrackList_UpdateAllExternalSurfaces()

But this also had no effect.

Thanks for the suggestions! I'll read through your code and see if I can mine it for further ideas.

[tack]

As we're nearing two years on this one I figured I'd give it ye ole futile bump.

This bug is really hampering the control surface experience in Reaper.

[Justin]

Hmm I think we can fix this, as a workaround the API you'd want to use is reaper.CSurf_OnTrackSelection() (call that on the track you desire and it should update the faderport to point to that track).

[tack]

Originally Posted by Justin

Hmm I think we can fix this, as a workaround the API you'd want to use is reaper.CSurf_OnTrackSelection() (call that on the track you desire and it should update the faderport to point to that track).

How did I miss that function! This workaround did the trick. Thanks Justin!

[tompad]

Originally Posted by Justin

Hmm I think we can fix this, as a workaround the API you'd want to use is reaper.CSurf_OnTrackSelection() (call that on the track you desire and it should update the faderport to point to that track).

Ooooh yeah!!

Had the same trouble as tack - Thanks Justin!!

[brummbear]

Is CSurf_OnTrackSelection(track) intended to actually select a track?

I cannot get it to work. Instead, I use:

int select = 1;
GetSetMediaTrackInfo(track, "I_SELECTED", &select);

That works without a problem. Selects the track and also triggers the callback SetSurfaceSelected properly.

What is CSurf_OnTrackSelection() meant to do?

[Justin]

Originally Posted by brummbear

Is CSurf_OnTrackSelection(track) intended to actually select a track?

I cannot get it to work. Instead, I use:

int select = 1;
GetSetMediaTrackInfo(track, "I_SELECTED", &select);

That works without a problem. Selects the track and also triggers the callback properly.

What is CSurf_OnTrackSelection() meant to do?

CSurf_OnTrackSelection() is meant to notify any control surfaces that a track was selected. It doesn't actually select the track.

[brummbear]

Ahh, I see. Thanks!

I was confused by the name starting with "On...". Typically this would indicate a call from the plugin to Reaper to update the project similar to other calls like OnVolumeChange(), OnPlay(), .. etc. Hence I would have anticipated a name like "SetTrackSelected()" instead - following the same logic like SetSurfaceSelected() etc.

Now that I understood I went on to confirm an observation that Breeder commented on in the SWS extensions:
https://github.com/reaper-oss/sws/bl...nsion.cpp#L528

I did some tests (Reaper 5.978) and can confirm that CSurf_OnTrackSelection() is only called when a track is selected via the mouse or the action "Track: Go to next track" or "Track: Go to previous track". However, the actions "Track: Select Track xx" (and there may be other actions too) will not lead to a callback! Whoops - this seems inconsistent. I would consider it a bug.

The widely used call GetSetMediaTrackInfo() will not lead to an automatic callback of OnTrackSelection if track selection has changed. One could argue that it is a deliberate design decision (not a bug), i.e. whoever uses it must explicitly call OnTrackSelection afterwards. Apparently opinions differ, see this "bug report": https://forums.cockos.com/showthread...17#post2002317

Anyhow, for the time being I will stick with SetSurfaceSelected() as the most robust callback to the plugin when listening to a change of selected tracks. This is somewhat less economical than OnTrackSelection as it is called also for unselecting tracks but I think a modern computer won't break down on that load

[michaelvogt@bluewin.ch]

.... another year later ...
After the release note
v6.05 - March 5 2020
+ Control surfaces: always follow track selection
The behaviour using actions like go to next / previous track is still the same - control surfaces do not always follow...
Own thread with a little test and documentation of that:
https://forum.cockos.com/showthread.php?p=2297885

Until this (not) always follow behaviour is solved - maybe before 2099:
Is someone able to post a "simple" lua example to go to next / previous track and informs control surface correctly to realy fallow? Just a useable work around for another four years or so *urbel gazurbel*?

[willpadgett]

I too would love to know if anyone's made a simple solution to updating control surfaces with 'next/previous track' actions, like the previous poster mentioned.