Add control surface feedback for sends and returns

[reaperaccessible]

I'm currently testing CSI 7.0 with an X-Touch Universal and OSARA.
Track controls and FX parameters are reported correctly via OSARA’s control surface feedback — including custom test widgets using the Speak action.
Initially, I thought the Speak test (e.g., "Hi my name is OSARA") didn’t work when assigned to Send or Return sections. However, after further testing, the Speak action works fine, even on Send/Return parts — so that part is behaving correctly.
To clarify:
In CSI, the Speak action is a function that speaks a hardcoded message when a widget is activated (e.g., pressing a button on the surface). It simply calls osara_outputMessage.
Actual Problem:
When touching Send or Return controls (e.g., volume on fader, pan on rotary, mute) from the control surface, OSARA does not provide any feedback — even though the widget is acting on a valid parameter.
My current understanding is that this might be related to how REAPER handles send/return state reporting. When focus is in the TCP, OSARA does not announce changes to send volume, pan or mute, unless the user explicitly navigates to the Sends/Receives section.
As a result, CSI’s control surface layer may be modifying those values, but OSARA isn’t picking them up or reporting them in real time.
Request:
• Extend OSARA’s control surface feedback system to report Send volume and pan changes when triggered via control surface input (e.g., via CSI).
• Ideally, spoken feedback would be consistent with existing parameter changes:
Let me know if I can help with testing — happy to assist however I can.
Environment:
• REAPER 7.41
• OSARA latest build
• CSI 7.0
• X-Touch Universal
• NVDA latest build

[jcsteh]

When focus is in the TCP, OSARA does not announce changes to send volume, pan or mute, unless the user explicitly navigates to the Sends/Receives section.

Can you elaborate on what you mean by "explicitly navigates to the Sends/Receives section"? What sends/receives section are you referring to? The only way OSARA can report these currently is via the Parameters dialog.

Note that the surface API only supports send volumes and pans. So we can't report mute, and receives will be reported from the perspective of the send, not the receive. If that's not satisfactory, please flag that now, as there's nothing we can do to fix that and there's no point sinking time into working on it if it's not going to be useful.

Technical note: Implement support for CSURF_EXT_SETSENDVOLUME and CSURF_EXT_SETSENDPAN in Surface::Extended.

[reaperaccessible]

Hi Jamie,
Here’s how it works:
When I call the CSI zone named SelectedTrackReceive.zon, CSI enters a mode where all the faders on the X-Touch are reassigned to control the receives of the currently selected track.
For example:
• Fader 1 controls Receive 1 volume
• Fader 2 controls Receive 2 volume, and so on…
• The same applies for pan, mute, pre/post via the corresponding widget mappings.
At that point, we are inside the SelectedTrackReceive zone for the selected track — and all hardware controls (faders, knobs, buttons) are now mapped to the receives of that track.
To resume normal track volume control, I have to exit the zone (e.g. by pressing a “Tracks” button), which returns me to the default zone (usually called Home.zon), where each fader again controls its assigned track’s volume.
This is a core design pattern in CSI: each section — such as SelectedTrackFXMenu.zon, MasterTrackFXMenu.zon, SelectedTrackSend.zon, Folder.zon, etc. — is its own zone, with completely independent mapping.
That means I can assign widgets differently in each context, even to dedicated actions or scripts.
For example, in SelectedTrackSend.zon and SelectedTrackReceive.zon, I can map and control:
• TrackSendVolume
• TrackSendPan
• TrackSendMute
• TrackSendPrePost
• TrackReceiveVolume
• TrackReceivePan
• TrackReceiveMute
• TrackReceivePrePost
However, none of these are currently vocalized by OSARA when triggered from the control surface.
Hope this clarifies how it works And don't hesitate if you have any other questions.

[jcsteh]

Your original comment suggested to me that OSARA does report the parameters if "the user explicitly navigates to the Sends/Receives section." But I don't see how OSARA could ever report sends/receives controlled from CSI. Is my understanding incorrect?

I also need answers to the other questions regarding whether reporting just send volumes and pans is useful, noting that mutes aren't possible and receives will be reported from the perspective of the send, not the receive. That's all we can do with the API.

[reaperaccessible]

Hi Jamie,
Thanks again — I really appreciate your patience and clarification.
You're absolutely right: OSARA does not report any changes made via CSI when controlling sends or receives from a surface. That part of my earlier message was poorly worded — sorry for the confusion. OSARA only reports those parameters if you're navigating inside the Routing window using the keyboard (TAB/arrow keys), not from surface interaction.
Also, you're correct in saying that receives are presented from the perspective of the sending track. That’s exactly how it works. But I’d like to add a small clarification:
In CSI, sends and receives are treated as two entirely separate sections, each entered via a dedicated button (or widget) on the surface. For example:
• Pressing one button might take you to the send section for the currently selected track (SelectedTrackSend.zon)
• Pressing another takes you to the receive section (SelectedTrackReceive.zon)
Once you're inside one of these sections:
• All the faders on the X-Touch are repurposed to control the relevant send or receive parameters
• If the selected track has no sends or receives, all the faders drop to zero
• As soon as you select a track that does have sends or receives, the faders automatically update to reflect the current parameter values
This is a consistent behavior across CSI zones, and it's one of its core strengths — it lets us map surface controls independently per section.
Regarding the API limitations — yes, I fully understand that mutes aren't accessible, and that receives are reported as sends. That makes sense.
However, I also understand that CSI is limited to what the REAPER control surface API exposes. If I discover that some parameters are simply not accessible via the current API, I’ll reach out to Justin to request possible additions. But for now, controlling send/receive volume and pan is already quite useful and appreciated.
Thanks again for everything you're doing — it's incredibly valuable to our community.
Best regards,

[reaperaccessible]

Ok, I asked Funkybot, CSI's collaborator and here is his reply:
I see Jamie's confusion.
CSI isn't limited to just the CSurf API. While it does use some CSurf calls, most of CSI’s features, including send/receive control, FX handling, and more use the full REAPER extension API (the same API available to C++ extensions and ReaScript).
There are many calls available in this API that aren't part of CSurf, such as:
• GetTrackSendInfo_Value
• TrackFX_GetParamNormalized
...just to name a couple. CSI uses these direct API calls to get or set information, then translates that data for control surfaces.
More details on these functions are here:
https://www.reaper.fm/sdk/reascript/reascripthelp.html

[ScottChesworth]

FYI, reading pseudo affirmations and over-explanations written by AI takes time that could be better spent resolving issues at this end of the equation. We'd prefer to communicate with you directly.

[reaperaccessible]

Hi Scott,
I use the tools I have at my disposal to express what I want to explain as clearly and precisely as possible in English, and to make sure things are translated properly.
Believe me — the AI often phrases things much better than I ever could on my own.
That said, I totally hear you. From now on, I’ll ask it to keep things shorter — just for you, because you're my idol.

[ScottChesworth]

From now on, I’ll ask it to keep things shorter...

Cheers

[jcsteh]

There's no confusion here. The confusion in the AI is that while that full API is indeed more versatile, it can only be used to get and set various properties. It cannot be used to detect when something else changes properties. To detect changes, you need to use the control surface API and that has a much more limited set of properties.

[reaperaccessible]

Ok so if I understand correctly, it is not possible to bring back the information to Osara if the CSI function does not use the API? Is this correct?

[jcsteh]

No. I mean that for sends, it's only possible to support volume and pan. Receives will be reported as if the user changed the send, as the surface API doesn't differentiate between sends and receives.