AZSlow

I don't think AZ Controller or other Sonar Surface API tool can help.

Sonar API is control surfaces oriented. It can filter incoming MIDI traffic with reasonable granularity, to avoid controls assigned for surface operations "leak" as normal MIDI messages into MIDI tracks. For MIDI output (and that is your case) from what I remember the possibilities are zero. The idea behind is to use device with just one MIDI port as normal MIDI input and surface. There is no such problem with output. While "control surface + MIDI keyboard" combination is common, I can't remember a single "control surface + synth" device.
Also there is "omni input" but no "omni output".

But even in case you somehow block what "song #2" sends on load. Before you play it, you want all that information is sent. So you need:
a) convince Sonar to re-send it at your will or
b) a program which can accumulate it  ("send suspended" state) and then play ("send resumed").
The first option is simpler to deal with, you just need to "block" before loading "song #2" and "unblock + sonar resend" before playing it.

I propose you ask on Cakewalk forum: https://discuss.cakewalk.com/
Don't write "Sonar X3", write just "Sonar". If you get some ideas for "new" Sonar, with high probability they will work for X3 as well  Noel and Mark are reading the forum. They know Sonar and they are smart.

---

If nothing from that is possible, you can re-work songs to avoid sending setup till you start playback. You can put all MIDI track options as explicit MIDI events (and deactivate every track control, if you ever touched it, f.e. 'Chorus', it is auto-activated and will send messages), explicitly send required SysEx / Bank changes / etc. Don't forget to unset "reset controllers on stop" in Preferences/Project/MIDI

That is also "future safe" approach. In case you ever change the DAW, copy MIDI with all related initialization will work (as long the DAW really support MIDI, not every DAW does that these days...) while related "in-daw" options may be significantly different (or not exist).

I posted this question on reddit and a helpful individual suggested I post it here.

We use sonar X3 and recently switched to a 2 laptop setup that both feed the same Motif rack for the midi sounds. When laptop #1 is playing song A and we load up song B on laptop #2 (to get it ready to play when song #1 ends), sonar sends the program change, volume, etc. info for song #2 and screws up song #1. In other words, as song #1 is playing through the motif, when song #2 is loaded (not started/playing) it sends all the midi commands to the motif.

Would AZ controller help us in any way? I opened up the documentation but nothing immediately jumped out at me.

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).