Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 11-19-2016, 10:10 AM   #1
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default Wrong track state sent to control surface for action or API-based track selection

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!

Last edited by tack; 12-30-2018 at 06:39 PM.
tack is online now   Reply With Quote
Old 12-29-2016, 02:31 PM   #2
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

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:

Code:
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:

Code:
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.

Last edited by tack; 12-29-2016 at 02:36 PM.
tack is online now   Reply With Quote
Old 12-29-2016, 04:11 PM   #3
nofish
Human being with feelings
 
nofish's Avatar
 
Join Date: Oct 2007
Location: home is where the heart is
Posts: 12,096
Default

Hi,

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

Quote:
Originally Posted by tack View Post
Code:
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.

Last edited by nofish; 12-29-2016 at 04:42 PM.
nofish is offline   Reply With Quote
Old 12-29-2016, 04:33 PM   #4
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

Quote:
Originally Posted by nofish View Post
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 is online now   Reply With Quote
Old 12-29-2016, 05:16 PM   #5
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

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 is online now   Reply With Quote
Old 12-30-2016, 01:23 PM   #6
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

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.
tack is online now   Reply With Quote
Old 01-02-2017, 01:04 AM   #7
Klinke
Human being with feelings
 
Klinke's Avatar
 
Join Date: Jul 2008
Location: Berlin / Germany
Posts: 832
Default

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
Klinke is offline   Reply With Quote
Old 01-02-2017, 11:16 AM   #8
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

Quote:
Originally Posted by Klinke View Post
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:

Code:
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 is online now   Reply With Quote
Old 12-30-2018, 06:35 PM   #9
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

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.
tack is online now   Reply With Quote
Old 01-01-2019, 05:08 AM   #10
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

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).
Justin is offline   Reply With Quote
Old 01-01-2019, 08:57 AM   #11
tack
Human being with feelings
 
tack's Avatar
 
Join Date: Jan 2014
Location: Ontario, Canada
Posts: 1,618
Default

Quote:
Originally Posted by Justin View Post
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!
tack is online now   Reply With Quote
Old 03-26-2019, 12:11 PM   #12
tompad
Human being with feelings
 
Join Date: Jan 2010
Location: Fjugesta, Sweden
Posts: 811
Default

Quote:
Originally Posted by Justin View Post
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!!
__________________
ToDoList Obliques MusicMath Donation Some of mine and my friends music projects on Spotify
tompad is offline   Reply With Quote
Old 05-22-2019, 04:20 PM   #13
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

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?

Last edited by brummbear; 05-23-2019 at 04:45 PM.
brummbear is offline   Reply With Quote
Old 05-23-2019, 06:37 AM   #14
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,721
Default

Quote:
Originally Posted by brummbear View Post
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.
Justin is offline   Reply With Quote
Old 05-23-2019, 04:42 PM   #15
brummbear
Human being with feelings
 
brummbear's Avatar
 
Join Date: May 2016
Location: out west
Posts: 301
Default

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
brummbear is offline   Reply With Quote
Old 06-05-2020, 11:39 PM   #16
michaelvogt@bluewin.ch
Human being with feelings
 
Join Date: Jan 2020
Posts: 12
Default

.... 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*?
michaelvogt@bluewin.ch is offline   Reply With Quote
Old 08-15-2021, 05:52 PM   #17
willpadgett
Human being with feelings
 
Join Date: Dec 2020
Posts: 35
Default

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.
willpadgett is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 02:20 PM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.