AZSlow
AZ Controller plug-in for Cakewalk SONAR => Discussions => Topic started by: norfolkmastering on September 02, 2023, 05:56:09 PM
-
Hi Alexey
The advanced copy of the new Cakewalk by Bandlab version: 2023.09 has just been released.
You may remember that you reported an issue to Mark McLeod that 'When destination (bus) is renamed, old name is reported by GetMixParamValueText(... MIX_PARAM_OUTPUT ...).'
You may remember that Mark agreed to provide a fix to clear the cache whenever Bus, Aux track, or Patch Points are renamed.
I just updated to the latest version and the problem appears to still remain.
I've attached the test AZ preset which I used to test.
I have also read through the bug fix list and the fix does not appear on the list.
As this is the last planned update to the free Cakewalk by Bandlab, I want to get this fix included in the final release.
I remember you preferred to deal with Mark on this so can you let me know if you are okay to raise it with Mark? or whether you want me to do it?
Link to the update and feedback is at https://discuss.cakewalk.com/index.php?/forum/36-early-access-program/
Regards
Robert
-
Hi Robert,
report your observation to Cakewalk, I don't have any special relations to them. Also I am not sure I can test anything next days (the end of vacation).
Alexey.
-
Okay I have reported as feedback in the early release topic.
-
Hi Alexey
I got a reply from Mark confirming that the new release of Cakewalk by Bandlab does clear the cache whenever Bus, Aux track or Patch Points are renamed.
They forgot to add it to the list of bug fixes on the new release documentation but it has been done.
So I did further testing of my system using:
Cakewalk by Bandlab Version: 2023.09 (Build 055, 64bit)
AZ V0.5r11 b422
AZ Controller Preset 'Bus Names v4 (I sent you a copy in last post)
Here are the issues I have observed:
1. When a bus name is changed, a track routed to that bus does not reliably trigger a corresponding AZ feedback. Occasionally a feedback output is triggered but most times not.
2. Changing a track send destination triggers the corresponding AZ feedback output only for track 1. Other tracks do not trigger AZ feedback when their send destination is changed.
3. Track send destination names are always reported as the stereo pair friendly names rather than the mono friendly name, e.g. a track send destination to 'DAW1' is reported as 'DAW1 + DAW2'.
I have written a major new enhancement for my mixer control software which will allow total flexibility of the number of tracks in Cakewalk within a project and will allow track slot positions to be rearranged whilst preserving the mapping of Cakewalk to mixer mapping. This is similar to what I have already been able to achieve for buses when I changed over to name based routing. However I cannot implement the new software until the issues I have listed have been resolved.
I would appreciate if you could test the above issues when you have time.
Best regards
Robert
-
Hi Robert,
I have replied in the Cakewalk thread. Sends related API is still broken (at least I can't get it work correctly...).
Changes in bus names seems like working ok for me with 'Bus Names v4' preset.
I can only return the destination name I get from Cakewalk... But somehow I have the feeling (not sure) that the "number" returned for the destination does not changed when switching between L/R/Stereo. Or that may be yet another consequence of reported problem with Sends, I mean the value is cached when it should not.
Note that in API mono outputs are "visible" as separate, but there is just one number for "destination" and no indication it is stereo or mono.
It seems like Cakewalk is using different API calls to get names for sends and outputs, bypassing these numbers. But from what I remember I have specially switched from it for target names,
to not overload Cakewalk. So the situation is somehow messy...
-
Hi Alexey
Thanks for the update.
1/
I repeated the bus names test and it is still not working for me. I made a short video to show you but I need to find a way to send you the video? It has a .mkv extension.
Can I email it to you?
Once you get the video, you will see:
When I change a bus name, then the change of name is correctly shown in the top row of AZ display and the SysEx message for the bus name change is output.
However you will see that the track output name is not changing in the second row of AZ display and the SysEx message for track output is not generated.
With many tests I found that it sometimes works with the first bus name change and then after that it fails to work.
2/
Thanks for contacting Cakewalk about the sends relate API issue. Hopefully they can provide a fix.
3/
It would be great if you could look at using the API call to get names for track sends. These are what I need to work with if it allows differentiation between stereo, left and right friendly names. If I cannot generate unique feedback outputs for these, then my enhanced track scheme is impossible.
Best regards
Robert
-
Hi Alexey
Further to my last post, I have uploaded the short video to YouTube. Link is https://youtu.be/rZoRIX9BfAc
Regards
Robert
-
If I understand Mark correctly, he has fixed something... let see when the next pre-release is uploaded...
-
Understood and agreed.
Regards
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
-
Hi Robert,
I have checked, Cakewalk still return cached names for outputs (so (2) is still on Cakewalk side).
Regards,
Alexey.
-
Okay I will contact them today.
Thanks
Robert
-
Hi Alexey
I just received an email from Mark McLeod.
Mark and his team have today tested the bus rename on three different control surfaces and they are all updating the track output names correctly.
Mark has told me that a bus rename does not trigger a topology update message and wonders if the AZ Controller is reliant on this for triggering the track output name feedback output?
Let me know please and I'll report back to Mark. If you prefer to email him then let me have your email address and I'll copy his reply to you.
Best 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.
-
Hi Alexey
Your explanation was very clear and I have passed on a summary to Mark.
It does not seem logical that, after a bus name change:
GetMixParamValueText(... MIX_PARAM_SEND_OUTPUT ...) returns new bus name
but GetMixParamValueText(... MIX_PARAM_OUTPUT ...) returns the OLD name for that bus
I have tested on my AZ preset and I can see this behaviour using the AZ display.
I just wonder if Mark has been been testing only the GetMixParamValueText(... MIX_PARAM_SEND_OUTPUT ...)?
I'll let you know what he replies next.
Thanks for staying with this!
Regards
Robert
-
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
-
Hello again Alexey
Latest from Mark:
ok, I've pinned it down.
I've put the fix into Sonar, but since CbB is now code-frozen I'll need permission to back-port it there, so there's a chance it won't make the final CbB release.
Waiting on the US to wake up with a decision on that.
So it looks like that's going to be sorted which is great.
I have one remaining issue which we've discussed before:
Track send destination names are always reported in AZ as the stereo pair friendly names rather than the mono friendly name, e.g. a track send destination to 'DAW1' is reported as 'DAW1 + DAW2'.
If I cannot generate unique feedback outputs for these, then my enhanced track scheme is impossible to implement.
So I'd be grateful if you could look to see if there is a AZ solution or whether this is definitely a core Cakewalk issue. If it's Cakewalk then all I can do is report it and wait a very long time for a fix in the new Sonar.
For completeness I used my test AZ preset to check both track send and track output name reporting:
Track Sends always report the Stereo friendly port name, e.g. DAW1+ DAW2, no matter whether the send is to Left, Right or Stereo audio port.
Track Outputs always report the Left friendly port name, e.g. DAW1, no matter whether the track output is routed to Left, Right or Stereo audio port.
I only need a fix for the track sends. I will use these to define the mapping relationship between a Cakewalk track slot and a tape machine (and mixer) physical track. So if I rearrange track slots in Cakewalk, the mapping relationship is not lost. So the tape machine (and mixer) always get the correct audio feed and the faders in Cakewalk always control the correct channels in the mixer.
So the track send name is (in effect) the track identity.
Let me know please if you consider there is a way to sort this in AZ.
Regards
Robert
-
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
Thanks for the feedback.
Just for clarification ...
Are you saying that the issue with the track send names is that Cakewalk do not provide the mono friendly names in the API?
If that is the case then I will speak to Mark about getting them made available in the Sonar release.
It would help me a lot if you could summarise how you currently fetch the track send names into AZ, so I mean the parameter name and anything else it would be useful for me to know in my discussions with Mark. This is the only remaining issue I need to solve so I can realise my final big control update, so I don't want to give up now!
Best regards
Robert
-
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).
-
Hi Alexey
Thanks for the explanation.
I want to be sure I ask Mark for the correct Cakewalk update, so let me try to summarise from my understanding. Sorry if this involves some additional questions.
My focus is still with track sends:
Can you confirm that GetMixParaValueText() is only returning the stereo friendly name even if the send is to a mono audio port?
If that is the case, then if I ask Mark to update the API so that GetMixParaValueText() makes available the correct name for each send to an audio port, so either left name, right name and stereo name, will you be able to provide the correct name for each send in AZ?
I do not need to know the stereo/mono nature of each send name. The friendly names I use tell me that.
If a Cakewalk update is needed, then I think that Mark will be willing to make the update as part of the first Sonar release BUT I need to ensure I am asking him for the correct update.
So I am really asking, what exactly do you need from Cakewalk to allow AZ to display the correct track send names?
Best regards
Robert
-
Hi Robert,
Yes, I display whatever Cakewalk returns.
Note that for me in current version Cakewalk is "buggy" by itself with sends. Even so it allows me to select "L", "R" or "S" initially, it display it without these characters. If I try to change the send, it also no longer display "L" "R" "S" in the list, even so there are still 3 items in the menu per stereo output.
-
Hi Alexey
The friendly names I use for the track sends do not use or require the "L", "R" or "S" suffixes.
Within the current track output select you get three names per audio port with the suffixes "L", "R" and "S
Within the current track send select, these suffixes have disappeared!
So, do you have a method in AZ to find 'correct' friendly name for the send which matches the name actually displayed in the send display (I mean in the track strip display just above the send level control)?
Or do I need to ask Mark for a modification to the API?
Regards
Robert
-
I have tried to explain why I can NOT use strips and HW names to find correct sends and outputs.
If you want changed is labels, you should ask CW.
I will say that is not a modification, it is fixing a bug. Obviously Cakewalk should show (and report to surface API) correct target names (including S/L/R suffix). In current version it doesn't even show the suffix for sends (in the selection nor in the inspector), so I guess the bug is not (or not only) in surface API related part.
But if the codebase is fixed, the only hope is the next version of "Sonar". Note that I probably will not get it (I am not ready to pay for it...).
-
Hi Alexey
I am sorry if I appear to be asking the same question multiple times. I am just trying to understand what I need to ask Cakewalk to modify.
So I will ask Mark to modify the surface API to report the correct track send names and see if he is willing to do it.
If it is only going to be updated in paid in Sonar and I decide to buy a license, then I will consider buying a license for you as well, otherwise I cannot get future AZ support.
Let's see what Mark says first.
Thanks again for all your help with this.
Regards
Robert
-
Hi Alexey
Mark has added the fix to get the surface API to report the correct track send names.
It will be a Sonar fix so I'll check out the free trial version of Sonar when it appears.
Best regards
Robert
-
Hi Robert,
Yes, I just report the label Cakewalk is giving me. Verbatim.
What Sonar will be, will it support the same API, how much it will cost, etc. are open questions. We just can wait till it is there.