Go Back   Cockos Incorporated Forums > Projects > Deprecated REAPER issue tracker > Closed Issue

Virtual Void SetSurfaceSolo doesn't get called when reaper track is soloed Issue Tools
issueid=1253 09-25-2009 02:06 PM
Human being with feelings
Virtual Void SetSurfaceSolo doesn't get called when reaper track is soloed
SetSurfaceSolo doesn't get called when reaper track is soloed

It seems the virtual void SetSurfaceSolo is ONLY called when you solo a track using the GUI/mouse. When you use an action, a midi CC, or Csurf_OnSoloChange gets called, SetSurfaceSolo is NEVER called.

SetSurfaceMute seems to work fine in this regard i.e. as soon as i mute a channel (through e.g calling CSurf_OnMuteChange) then reaper calls SetSurfaceMute. The funny thing is that it also calls SetSurfaceSolo, which in my opinion isnt necessary.

I need this to built proper csurf code.
Issue Details
Issue Type Closed Issue
Project Deprecated REAPER issue tracker
Category Plugins
Status Live With It For Now
Priority 3
Affected Version 3.11
Closed Version (none)
Yes votes 1
No votes 1
Assigned Users (none)
Tags (none)

09-28-2009 01:58 AM
Human being with feelings
 
I think I have something similar going on with IReaperControlSurface::OnTrackSelection(). It is called by UI/mouse selection and IReaperControlSurface::CSurf_OnTrackSelection() but not by actions/shortkeys or Main_OnCommand(). Maybe more IReaperControlSurface::CSurf_On*() methods have this problem, I shall investigate.

BTW should we report dev related stuff in this forum or in the dev forum?
Reply
09-28-2009 02:49 AM
Human being with feelings
 
Maybe I am not using the API in the appropriate way. When i press a button on the surface, I call : CSurf_OnSoloChange in order to change the solo state within reaper. That seems to work fine i.e the solo indicator i reaper is lit. With mute/select/rec-arm, reaper immediately then calls the appropriate virtual void (SetSurfaceMute/...), except with Solo, then it refuses to call SetSurfaceSolo

I never used CSurf_SetSurfaceSolo (or CSurf_SetSurfaceMute...) in my code. What is actually the reason for this call ? I always thought that the CSurf_OnXXXXChange was from surface to reaper, and from reaper to surface was handled with the SetSurfaceXXXX virtual voids. Maybe i am missing a step.

I guess as now we're discussing, perhaps we should move this back to the dev forum :-|
Reply
09-29-2009 12:35 AM
Human being with feelings
 
Not a bug: apparently you always need to call CSurf_OnXXXChange through CSurf_SetSurfaceXXX e.g CSurf_SetSurfaceSolo(tr, CSurf_OnSoloChange(tr,i), NULL);

Yves
Reply
09-29-2009 12:37 PM
Human being with feelings
 
I confirm for TrackSelect too: not a bug
Reply
01-08-2010 07:08 AM
Administrator
 
Related:

Quote:
Originally Posted by Geoff Waddington View Post
The SetSurfaceSolo function does indeed get called but the MediaTrack is always the Master Track (track id 0), regardless of which MIDI message triggered the OnSurfaceSolo call.

Triggering the callback from the GUI sends the correct MediaTrack to the SetSurfaceSolo function.

This seems to suggest a bug in OnSurfaceSolo, or somewhere downstream from there, in triggering the callback function.

The other functions I've investigated so far -- SetSurfaceRecArm, SetSurfaceMute, SetSurfaceSelect, and SetPlayState behave as as expected, only Solo shows this behavior, and there is no need to "wrapper" them as suggested in the quote.
Reply
01-09-2010 07:30 AM
Human being with feelings
 
i'm fine with re-opening this bug, but it does seem that geoff's observation is different than the description i used at the time.

Yves
Reply
10-17-2014 12:52 AM
Mortal
 
Closing this issue as "Live with it":
- as yhertogh said, the original report wasn't a bug,
- and, to clarify Geoff Waddington's 2nd "issue", when IReaperControlSurface::SetSurfaceSolo is called with the master track as 1st param, your CSurf code must either ignore it, or interpret it as "any solo" (e.g. w/ MCU type of controllers, you have a light that signifies that something is soloed). Also, there is no bug here, because SetSurfaceSolo is properly called for a solo'ed track, and then, there's that other "any solo" call with the master track.

Note: claryfing this issue because I was fooled by it in SWS too... using the master track to notify "any solo" is questionable but since some existing csurf rely on this, we'll have to stick with it...
Reply
Reply

Issue Tools
Subscribe to this issue

All times are GMT -7. The time now is 03:10 AM.


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