azslow3 Posted February 17, 2023 Share Posted February 17, 2023 When destination (bus) is renamed, old name is reported by GetMixParamValueText(... MIX_PARAM_OUTPUT ...). I can't tell since when, but I remember a discussion about some "caching for names" not long time ago. In Sonar X2 it is working correctly. CbB version: 2022.11 (build 021, 64bit) Link to comment Share on other sites More sharing options...
norfolkmastering Posted February 17, 2023 Share Posted February 17, 2023 I am getting the same issue on the current version of Cakewalk by Bandlab. Would someone from the development team be able to check if they see the same issue? Link to comment Share on other sites More sharing options...
msmcleod Posted February 17, 2023 Share Posted February 17, 2023 Thanks for the report - we'll look into it. [EDIT] - Found & fixed the issue for the next release. Normally, the cache isn't cleared unless the project topology graph has changed (e.g. routing changes or adding/removing tracks). Bus routing and their names are cached, because it needs to walk the topology graph to find them - this takes time, which is why we introduced the cache in the first place. Track names however are instantly available, so they're grabbed in real-time. The fix was to clear the cache whenever Bus, Aux track, or Patch Points are renamed. 1 Link to comment Share on other sites More sharing options...
azslow3 Posted February 18, 2023 Author Share Posted February 18, 2023 Thanks! In my current dev version of AZ Controller I try correctly cache names when possible (previous behavior was not optimal and buggy...) . That is how the bug was spotted. Since I slowly checking for names, once a change is noticed I re-check output/send names (if they are used for feedback). May be it is time for me to check if CbB: (a) trigger topology change flag for refresh when output or send output are changed (the last by surface) (b) if outputs/sends to side-chains and auxes are controllable. I am still developing under X2, may be there are some improvements 😏 1 Link to comment Share on other sites More sharing options...
msmcleod Posted February 18, 2023 Share Posted February 18, 2023 AFAIK I don't think the timing of topology change messages has changed much since X2, apart from the obvious introduction of Aux Tracks & Patch Points. Basically ANYTHING that changes the routing will trigger a topology graph change, so that includes: - Adding/Removing Tracks, Buses, Patch-points or Aux Tracks - Adding/Removing Sends - Changing any inputs or outputs - Adding/Removing Effects - Enabling/Disabling input or output ports This particular scenario was different, as the routing itself hadn't actually changed - only the name of the ports had. The control surface cache is reset: - Any time the topology changes - Any time the track or bus ordering changes and in the next release... - Any time a bus, aux track or patch-point is renamed As far as controlling sends are concerned. You can't change the destination of the sends via the API, but you can: - Enable/Disable a send - Change the send level - Change the send pan - Change it to pre/post Link to comment Share on other sites More sharing options...
azslow3 Posted February 20, 2023 Author Share Posted February 20, 2023 On 2/19/2023 at 12:15 AM, msmcleod said: As far as controlling sends are concerned. You can't change the destination of the sends via the API, but you can: You can... That was never possible if the output was to side-chain and I remember there was problems with AUXes (since reply what is current output returns error, at least for side-chains), but changing bus to other bus is working fine. Well, if there are several sends, changing the output can auto-reorder sends, which for me is a bug, but that is not surface specific. Surface can't see topology graph, it just get a flag "topology changed" as refresh parameter. And the flag is not set when track output is changed, nor when send output is changed by surface. At least in X2. Link to comment Share on other sites More sharing options...
norfolkmastering Posted February 20, 2023 Share Posted February 20, 2023 Just to echo Alexey's post above that I have been able to control the destinations of sends using AZ Controller. I use AZ to set sends to any external audio port using the port's friendly name. The issue I do have (which I think that Alexey alludes to above) is that I can't get any feedback from the Cakewalk API when a send destination is changed (whether that be done using the Cakewalk GUI or whether I do it via AZ Controller). Is there a way to make the current send destination 'friendly name' readable via the API? Link to comment Share on other sites More sharing options...
norfolkmastering Posted March 7, 2023 Share Posted March 7, 2023 Mark Just a note to say that in my tests, changing a send destination does not seem to be triggering a topology graph change. Would you mind checking this as part of the update work for the next release? Link to comment Share on other sites More sharing options...
msmcleod Posted March 7, 2023 Share Posted March 7, 2023 4 hours ago, norfolkmastering said: Mark Just a note to say that in my tests, changing a send destination does not seem to be triggering a topology graph change. Would you mind checking this as part of the update work for the next release? Just checked that now. In every project I've tried, the REFRESH_F_TOPOLOGY flag is definitely being set when a send destination is changed. This code hasn't changed since 2006. Are you actually changing the send destination, or just renaming it? Link to comment Share on other sites More sharing options...
norfolkmastering Posted March 8, 2023 Share Posted March 8, 2023 I am changing the send destination but it's possible the flag is not being read by AZ Controller. Alexey will check this once the next Cakewalk release is available. Any idea when that might be? Link to comment Share on other sites More sharing options...
azslow3 Posted March 8, 2023 Author Share Posted March 8, 2023 14 hours ago, msmcleod said: Just checked that now. In every project I've tried, the REFRESH_F_TOPOLOGY flag is definitely being set when a send destination is changed. This code hasn't changed since 2006. Are you actually changing the send destination, or just renaming it? Are you sure that is the case when you change by the API? Sure it can be my bug, but in my observation the flag is set only in case you change is done by mouse. Link to comment Share on other sites More sharing options...
msmcleod Posted March 8, 2023 Share Posted March 8, 2023 4 hours ago, azslow3 said: Are you sure that is the case when you change by the API? Sure it can be my bug, but in my observation the flag is set only in case you change is done by mouse. That would make sense. Cakewalk only tells you things it's changed. If you know you've changed via the API, why do you need Cakewalk to tell you what you've changed? Link to comment Share on other sites More sharing options...
norfolkmastering Posted March 8, 2023 Share Posted March 8, 2023 2 minutes ago, msmcleod said: That would make sense. Cakewalk only tells you things it's changed. If you know you've changed via the API, why do you need Cakewalk to tell you what you've changed? In the tests I have done, I am changing the send destination in Cakewalk by mouse, but I get no output from AZ Controller unless I change somethings else to invoke a refresh (e.g. a track destination). Link to comment Share on other sites More sharing options...
msmcleod Posted March 8, 2023 Share Posted March 8, 2023 The refresh is sent out many times a second. The refresh includes a status - this is a bit mask, so there could be more than one flag set. One of these flags is the REFRESH_F_TOPOLOGY flag. If AZ Controller is looking for the REFRESH_F_TOPOLOGY flag on its own, that may be the issue. Link to comment Share on other sites More sharing options...
azslow3 Posted March 9, 2023 Author Share Posted March 9, 2023 18 hours ago, msmcleod said: That would make sense. Cakewalk only tells you things it's changed. If you know you've changed via the API, why do you need Cakewalk to tell you what you've changed? I expect Cakewalk inform me when something is changed homogeneous way. Asking Cakewalk to do something does not means it has done that immediately, it can be not possible or is done later. Well, that is not so important, I am just monitoring the value without caching now. @norfolkmastering AZ Controller specific processing is relevant for AZ Controller only. There are times Cakewalk does something not possible to "fix" in AZ Controller, like original BR, and there are times AZ Controller does something unexpected, like your last observation. Lets not disturb Cakewalk with something they do not manage Link to comment Share on other sites More sharing options...
norfolkmastering Posted March 9, 2023 Share Posted March 9, 2023 Understood. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now