AZSlow

Hi Robert,

Lets hope there will be fix for Output name or at least stable workaround which I can implement. For sends I guess I can't do anything on my side.

And for the future... will see what Cakewalk will do with "new" Sonar, including how compatible it is going to be with old Surface API. Recent problems with sends and outputs
was regression, in X2 it was working fine. So there can be more regressions when they do more changes (and they obviously will...).

Alternative approach will be integration with REAPER. There is no AZ Controller for it (after all these years I still have not found the time to write it...), but API is truly complete and well supported. While Cakewalk is "exporting" special API for surface integration, REAPER just expose most essential internal functions, usable for surfaces, extensions and in MIDI/audio plug-ins.
So you can add your device specific elements into menus, modify the project structure and all properties, etc.

There are successful projects syncing DM (f.e. X32) with REAPER. Dedicate (C++) code is in fact not so difficult to write.

Hi Alexey

I had a further email from Mark and I did further tests which are both summarised below:

From Mark:
From what I can tell, MIX_PARAM_SEND_OUTPUT isn't using the cache but MIX_PARAM_OUTPUT is.

The way the cache works is that it checks to see if the string exists in the cache, then returns it if it exists. Otherwise it goes through the normal lookup procedure and adds it to the cache.

When you change topology, or perform a host of other operations (such as renaming a bus), the cache is simply cleared.

The behaviour your describing would suggest the cache isn't being cleared.  So I guess the question is, how are you renaming your bus?

I've tested double clicking the name and using F2 on both the bus header strip in the tracks view, and also the console view.  I've also used the track properties pane in the inspector.

All of them result in the cache being cleared, and the new name being returned.

My tests and response to Mark:
If I rename a bus from the console view, then AZ Controller does not get the updated track output name, so MIX_PARAM_OUTPUT is not refreshing.

If I rename a bus from the track view using the track inspector, track properties, then AZ Controller does not get the updated track output name, so MIX_PARAM_OUTPUT is not refreshing.

However, if I rename a bus from the track view, using the bus panel, then AZ Controller does correctly update the track output name so MIX_PARAM_OUTPUT is being refreshed.

In all three methods of renaming the bus, MIX_PARAM_SEND_OUTPUT is always refreshed with the new bus name.

I have tested this a number of times and the above is 100% consistent.

I hope this helps points towards the issue.  I'll also forward your observations below and my response above to Alexey.

Alexey
There is clearly a bug in that one of the three ways of renaming a bus is correctly triggering the refresh of MIX_PARAM_OUTPUT but the other two methods are not.
If you can repeat my tests, that would be helpful.  Let me know if you want me to make a short video.
Hopefully this will help Mark diagnose the issue.
If you have any further comments on any of the above, please let me know and I will forward to Mark.
Regards
Robert

Hi Robert,

I am using GetMixParamValueText(... MIX_PARAM_OUTPUT ...).
After renaming the bus, GetMixParamValueText(... MIX_PARAM_SEND_OUTPUT ...) returns new name (in case the send is pointing to that bus),
but GetMixParamValueText(... MIX_PARAM_OUTPUT ...) returns OLD name for that bus. Note that in my log (from the preset we are testing) the calls are in mentioned order,
so new bus name is definitively "known" when I ask for the output name.

I will check tomorrow which version I am really using, I have just updated CbB without remembering the version I got. But since sends are working now, I guess I have what
they have uploaded.

I can also check what they are using for surfaces and use the same way to get the name. But I still believe there is some bug. And if that is the last update,
I guess we better clarify it now instead of introducing a workaround in AZ Controller.

The fact topology flag is not set after some relevant changes just force me "re-scan" related parameters/labels continuously. That is inefficient, especially when for internal
reasons related API calls are "heavy" for the DAW, but works...

Cheers,
Alexey.

Okay I will contact them today.
Thanks
Robert

Hi Alexey

A further interim release of Cakewalk by Bandlab has just been released. V2023.09 (Build 062, 64bit)
So I retested the two issues which we were hoping would be solved by this update.

1.  Changing a track send destination now triggers the corresponding AZ feedback output for all tracks reliably.

2.  When a bus name is changed, a track routed to that bus still does not reliably trigger a corresponding AZ feedback.  Only very occasionally, a feedback output is triggered.  I did 50 tests of changing the bus name and only 2 times was the AZ feedback output triggered.

I would would be grateful if you could check point 2. above at your end and let me know if you think it is still a Cakewalk software issue or something to be sorted in AZ Controller please.  There is probably only a small time window to request further fixes in Cakewalk before the release is made public.

Regards
Robert