AZSlow

Sorry it took so long. I have done a quick check under 2025.2 and it works as expected. I have uploaded version with modified manifest.
I wish some user could do compatibility tests when new NVDA version appears and report most overlays are or are not broken. For known reason, I am not using this software for myself, till something is incompatible in general, I will not notice problems during quick checks I do.

I have managed to check. In 1.9.0 OSC compatibility mode everything is working as expected.

The latest driver 1.276, from 9.7.25
Totalmix 1.99, was installed with this driver

So install the latest.

Got it, so if I'm understanding correctly the way things stand now, it makes sense at present to get 1.9.5 of TotalMix installed on the primary machine. Does 1.9.5 need a 1.9.0 fallback mode for OSC enabled, or is that a 1.9.6 addition that, even wen enabled, causes problems when routing or switching outputs?

I am not able to test compatibility with the latest RME driver till the middle of the next week.

Just to confirm: Driver version 1.95, not 1.96, is still the best way to access the full range of capabilities for the Babyface ProFS that AZOSC has to offer? I saw the post about 1.96's brokenness and wanted to ensure I did not install it if such was the case. New Babyface ProFS is arriving any day now. I'd be ok experimenting as I do have a second computer that I can easily install 1.96 on that has no intentions of being a DAW computer. So if the xml can in fact be modified for 1.96, is RME still approachable for getting updated OSC command sets?

I have published 0.0r5 version as new production version and updated installation instructions.

@miltonsica: I suggest you remove manually installed JSFXes (and corresponding lines in reaper-jsfx.ini) and upgrade ReaCWP. Test versions of ReaCWP and effects are NOT compatible with final versions (so it is good I have not published them... making them "compatible" could be challenging, I have understood that after defining ReaPack delivery method).

FX Chains, Containers and Modulation
"FX Chain" in CW is a special "container effect". In REAPER "FX Chain" is "FX Bin" (or just a sequence of effects). Please don't be confused by that change in terminology.

Starting from version 7, REAPER also has special "container effect" called "Container". Note it was introduced to allow parallel processing using several effects inside one strip, so not as a "black box with macro controls". Technically it can be used as a replacement for "FX Chains" in CW, but "Macro controls" have to be organized separately.

REAPER can modulate values of (automatable) effect parameters using values of other parameters, LFOs or audio signals. The only (known to me) related feature in CW is "Macro controls for FX Chains". The logic behind and so the configuration are a bit different. In the following I try to explain how to reproduce "FX Chain" macro controls in REAPER. That is done automatically by ReaCWP.

1. Create Container with all required effects. If you don't have any effect in the strip yet, you can only add "normal" effect when you click "FX" button. So add all (or at least one) effects you plan to use, put "CoControls" JSFX at first place. Select all these effects and "Move FX to Container" from the context menu.
2. I recommend rename (F2) the Container to the name of your "FX Chain" and rename "CoControls" to the same name with appended " Ctrl".
3. CoControls always has all "parameters" defined, with fixed names (unlike "FX Chain"). But you can change the appearance (GUI), right clicking on any defined control. After that I recommend "Alias parameter" from "Param" menu and use Label name for corresponding control. Then "Map to container parameter" these parameters (also in "Param" menu) and "Alias parameter" again, this time for Container. Mapping and extra aliasing is not required, but if you want automate macro controls or add them as Track controls, they have to be mapped.
4. Modulation in REAPER is configured for the target parameter (in "FX Chain" that is an option of macro control). "Macro controls" of CoControls are just "some parameters" (which by themself control/change nothing).
- Open target effect UI and change parameter you want to modulate. Then you can use "Parameter modulation/MIDI link" in the upper part of "Param" menu. Otherwise use named the same option in the lower part and select desired parameter by name. Modulation dialog should appear.
- Check "Link from MIDI or FX parameter". Select "CoControls" (it will be named differently if you have followed my suggestion) and required source parameter (which should be reasonably named if you have followed my suggestions).
- To reproduce "Range" of "FX Chain" control:
* move the control in CoControls to  0%/Off
* Set "Offset" to zero (default), and it will stay at zero (not useful for "Macro controls").
* Looking at target effect UI, move "Baseline" slider (the first one at the top) to the position corresponding to 0% position of Macro control.
* move the control in CoControls to 100%/On
* Looking at target effect UI, move "Scale" slider till target parameter has desired for 100% value.

In other words, "Baseline" is "From" value of "FX Chain" modulation, "Scale" is "To"-"From" of "FX Chain" modulation (can be negative!). F.e. "from 80% to 20%" in "FX Chain" means "Baseline 80%" and "Scale -60%".

And don't worry if you are confused at first, I have also originally tried somehow bring "Offset" into that procedure  Just to void future confusion: "Offset" is applied after "Scale", if you ever going to try it

Starting testing standard FX Chains presets from X2, I have already spotted 2 bugs in FX Chains... One of them can increase warning counter in the version you have, but that is not worse new build/upload. I have not checked if in current Sonar these bugs are fixed.

But I want mention them, so you don't count that as ReaCWP bugs:
1) some specified for FXChain controls can be NOT shown in Cakewalk. They are perfectly fine, converted and shown in REAPER. Editing the position of such control in Cakewalk (which for user appears as "not used") produce "ghost" control (with bad parameters). ReaCWP will ignore them silently, but till next build generate warning.
2) modulated parameters in REAPER can have "wrong" values (not the same as originally in Cakewalk) or the state of the control can be different from original (f.e. you see the button is "off" in Cakewalk, but it is "On" in REAPER). That can happened with parameters which have "custom range" (not default 0-100%) for the first parameter they modulate. Initially Cakewalk takes actual target parameter value as the value for macro control. The bug is with range, they don't apply "reverse custom range" to this value. F.e. if range is 20-40% and target parameter is 0.4, Cakewalk will NOT set button value to 1 (on), it will set it to 0.4 (shown as off).
In particular case where I have spotted that, the indication was wrong in Cakewalk but correct in CoControls. But that is case dependent, can go in any direction (both show wrong value, any set wrong value, etc.).
In practice, once control is "touched" in Cakewalk, correct value for it is saved and everything should work correctly (in Cakewalk and in REAPER).

I have sent you PM (on this forum) yesterday.

BTW I am not sure in which build I have fixed that, can be you was using some version with problem: Container default "Mix" parameter is 50%. It is 100% when you create it in REAPER and in PMed ReaCWP (which set it explicitly).

No problem. I'll use the new version separately, keeping the last one that helped me complete the trip.

Can you send me a private message?