Hi Robert,
API has GetMixParamValue() and GetMixParamValueText() methods. The first returns numeric value and the second corresponding text. So for sends and outputs I can get the "value" and then ask for its meaning. For reasons you probably remember, I and Cakewalk tries to cash both as far as that make sense (especially in AZ Controller it can happened you need the same value or text several times within one monitoring loop, f.e. to check the value/text is changed and later to send it to your device). If cashing is implemented incorrectly, corresponding value or text is not updated. Obviously that can be wrong on both sides, so I periodically "guess" the problem is in Cakewalk and Mark guess it is in AZ Controller. In worse case it can be on both sides
I just get "the text", I can't guess it is about mono or stereo. Cakewalk API (I guess for historical reasons) expose the number in the "whole list" of targets, including stereo/mono/different types of targets. BTW it also does the same for MIDI, including in project persistence, I guess that "feature" is responsible for many strange MIDI routing bugs in Cakewalk history. So nothing can be done on my side.
I am slowly updating all strip names, with different API methods. So I can detect when something is renamed, even without "topology is changed" flag. Obviously that works in case Cakewalk flash the cash correctly (that is why "bus names" in the test preset was not updating before recent fix from Cakewalk). But I can't use that information to update Output nor Send, because I can't guess which "value" correspond to which strip (sends/outputs can be to buses, hardware outputs, auxes and side chain plug-in inputs, I have no direct info about the number of last 2; also the target can't be the strip itself (in case of buses), so there are some "skips"; the list of strips exposed to surface can be different from real (strips "visibility"); there is no way to get UID for target,
unlike f.e. in REAPER).