With regard to FX Chains, the API return value of getMixParamLabel for MIX_PARAM_FX has been changed from "FX Chain" to "{fx chain name}"
Note the {} around the new expression.
Sometime ago Cakewalk introduced the very useful feature to be able to give FX Chains custom names and this new API update reflects this. I use custom names as it allows me to identify the FX Chain in use for a particular track.
Unfortunately this change caused the FX Chain controls I had programmed in AZ Controller to stop working. I had been using the Logic action e.g.
FX FX Chain shift 0 parameter 4
So the "FX Chain" name was no longer recognised.
I tried changing the "FX Chain" names to the custom name for each track's FX Chain, e.g. to:
TRACK1 FX Compressor1 shift 0 parameter 4
TRACK2 FX Equaliser6 shift 0 parameter 6
However this stops working as soon as you rearrange the order of the tracks in Cakewalk.
One solution for me was to use the Logic action e.g.:
FX <any> shift 0 parameter 4
However I reported the issue to Mark McLeod at Cakewalk and he has kindly added a hook so that all FX Chain names will be reported as "FX Chain" irrespective of how the custom name is set.
This hook is actioned by adding the following configuration lines to the Cakewalk.ini file
ReturnUserFXChainNameToControlSurfaces=0
AlwaysUseShortPluginNamesForControlSurfaces=1
I tested this today and it works.
Regards
Robert
Hi Alexey
Now that Cakewalk Sonar has the option to return the custom name of a track FX Chain in the API, is there a way to read and report this name in AZ Controller?
Regards
Robert
Hi Robert,
I am not aware about API changes, API definition is not changed since 11 years:
https://github.com/Cakewalk/Cakewalk-Control-Surface-SDK/tree/master/Framework2
(ControlSurface.idl, I am NOT using API C++ wrapper)
What sometimes changes is behavior of API, and this time I guess is the same.
So Cakewalk can return "FX Chain" or "{fx chain name}", but not at the same time (as you write, what is returned is controlled by options). And so if you use "FX chain", I can't get the name. If I get the name, it replaces "FX Chain".
FX Chains are not something special from all perspectives, they are just yet another FXes. The only difference they can host other FXes and so parameter names and the list of parameters can be different in each instance (and I remember I had difficulties with that, in ACT Dynamic mapping, since it doesn't report which type of FX/Synth it currently controls).
If Mark knows the way how to get "user name" for FX Chain when API reports "FX Chain", I can add the feature to AZ Controller.
Regards,
Alexey.
Hi Alexey
I am sure you are correct that the basic API definition is unchanged.
What Mark told me is that, with the introduction of custom names for FX Chains, the latest Sonar release returns (by default) the actual custom FX name enclosed in {}.
Prior to that recent update, FX Chains with custom names always returned "FX Chain"
Here is his post from the Sonar Beta tester forum:
'The only thing that has been changed with regards to FX Chains is the return value of getMixParamLabel for MIX_PARAM_FX.
It used to always return "FX Chain". Now it returns "{fx chain name}".'
With my AZ Controller configuration, this caused my track ident function to fail.
So Mark introduced an optional hook, actioned by adding the following configuration lines to the Cakewalk.ini file
ReturnUserFXChainNameToControlSurfaces=0
AlwaysUseShortPluginNamesForControlSurfaces=1
This causes the return value of getMixParamLabel for MIX_PARAM_FX to always return "FX Chain"
This fixed my issue.
However, I realised that I could use the custom FX Chain names to simplify the way I do my track idents, so I'm looking at that now.
I have just found out that I can get the custom FX names reported in the AZ feedback actions by using the action:
Text, Param. name, Container
This seems to work correctly.
Best regards
Robert
Hi Robert,
the only ideas I have at the moment, I can add "Named FX Chain" ("{*}" pattern) to the list of possible FX name selections (currently "Any" or some particular name) and remove '{}' from names (the result of Text, Param. anme, Container), if that will help you.
Regards,
Alexey.
Hi Alexey
In feedback, the action Text, Param. name, Container
seems to be returning the FX Chain custom name correctly, so don't spend any time on this for now.
I'll get back to you when I've finished my updates.
If successful then I can remove the need to use an FX control parameter as the track ident proxy.
Thanks and best regards
Robert
Hi Alexey
I finished the update to use the custom FX Chain names as track and bus idents.
There is one major issue which I would ask you advice about please.
I will describe the test sequence:
1. Insert an FX Chain preset to bus slot 1.
Timestamp 427839 outputs the correct MIDI message with the MIDI value representing the custom FX Name.
2. Delete the FX Chain in bus slot 1 and then I get two MIDI messages from AZ:
Timestamp 439639 outputs an INCORRECT message showing the PREVIOUS status, i.e. when the FX Chain is present (even though the FX Chain has been deleted).
Timestamp 439676 outputs the correct message when there is no FX Chain.
This additional INCORRECT message is causing big errors in my system and I cannot find a way to stop it outputting.
This additional INCORRECT message does not happen when I just report the value of an FX Chain control. It only happens when I report the FX Chain custom name.
I have images to show the AZ preset and MIDI-OX messages but I cannot understand how to load images on this forum now. It used to be possible.
I would be grateful for any suggestions to fix the issue.
Regards
Robert
Please upload your current preset. Can be its logic related.
a)I "slowly scan" for structural changes, doing so every cycle is not practical (some API calls as relatively slow). That can theoretically produce wrong report, when AZ Controller has already spotted the change, but has not upgraded all related information yet.
b)It can also be Cakewalk is reporting outdated information.
In any case, that can be checked and fixed (in case of a) or workaround (in case of b), once I understand from where it comes.
PS since I don't have new Sonar, I can only work in "demo mode". I hope the behavior is the same.
Hi Alexey
Thanks for your help with this.
This is the first time I have used this action combination so I will check if the issue exists in Cakewalk by Bandlab. If it does then I will send you a test AZ Controller preset using CbB.
If the issue only exists in Sonar then I will send you a test AZ preset for use with Sonar.
It will be easier to see the issue in a small test AZ preset, so I will only send you my current very large preset if I cannot demonstrate the issue any other way.
Regards
Robert
Hi Alexey
I have attached a test preset which works with CbB and shows the issue.
When the Monitor parameter value priority is set to Ultra then you always get the additional feedback message when the FX Chain is deleted.
When the Monitor parameter value priority is set to Slow then you do not get the additional feedback message when the FX Chain is deleted.
Could you have a look please and see if it is possible to stop the additional feedback message irrespective of the priority setting.
Regards
Robert
Sorry for no reply so far, it can take some more days till I can test it...
No problem, thanks for keeping in touch.
Sorry for delay.
The problem is a bit complex. Please use https://www.azslow.com/index.php?action=downloads;sa=view;down=28
(test version). The modification can have side effects.
The monitor will be (still) triggered 2 times, but with this version it should not produce wrong results (at least for FXes).
Really you can correct the preset and it will work without new version, by checking "Selection:Valid" condition to detect FX is no longer there. Note you have to initially set Text to "" in any case (as you do with TKIDENT->Default), "Text Parameter" will not work in case parameter is not there or for other reasons, leaving text you compare untouched.
The difference in new version, "Text Parameter" really should no longer work in this particular case. It was returning old name before.
----
The problem is in my cache and Cakewalk behavior (always was like that, reproducible with X2).
Cakewalk normally inform surface plug-ins there are some structural changes. Even that is not always, but I think for FX removing it should do that.
Unfortunately, I see there is "idle" call before such notification. So, first monitor just "fail" to get values, thinking there was no structure changes. And next time, after Cakewalk triggers structure change notification, it detects "no longer there" condition.
In previous version, I was returning cached values in many cases (f.e. for container name) without reacting on "failures" at all. So even so the monitor was (correctly) triggered and setting "Selection:Invalid", "Text Parameter Container" was still returning cached values.
Hi Alexey
Thanks for looking at this issue for me.
First I added the set Text to "" as the first action in the Tk1IDENT Feedback list.
Next, I decided to experiment with the "Selection:Valid" condition.
I added the "Selection:Valid" condition to Parameter name action in the Tk1IDENT Feedback list.
This produces the correct Feedback output value when the FX Chain is deleted from the Cakewalk track, but it outputs the correct value twice.
Next I added the "Selection:Valid" condition to Parameter name action in the Tk1IDENT Logic list.
This produces the correct Feedback output value when the FX Chain is deleted from the Cakewalk track but only once.
This is working reliably on the test preset even with the Monitor action set to Ultra.
I will try this on my full console preset in Sonar and let you know how it works there.
Regards
Robert
Hi Alexey
The potential solution I described in my last post does not work in Sonar.
Adding the "Selection:Valid" condition to the Parameter Name Monitor action in the Tk1IDENT Logic list stops the Parameter Name Monitor from triggering.
Adding the "Selection:Valid" condition to Parameter name action in the Tk1IDENT Feedback list only, allows the correct Parameter Name Monitor output value, but this outputs twice when the FX Chain is deleted.
The second output is a problem for me as it disrupts a chain of events triggered by the first output.
Is there any way to stop the second monitor output (when the FX Chain is deleted)? I might be able to trap it safely in my PIC code but as its timing is very variable, it will be difficult to trap reliably.
Regards
Robert
Hi Robert,
I propose you find some solution which is "able" to accept double triggering. In general you better design everything assuming any parameter monitor can be re-triggered more then once.
The problem is that (parameters) monitor can be triggered by different events. Value change, Name change, container change, project change, etc. Which changes are important and which not is at the end device dependent. F.e. when you monitor parameter value of the first FX parameters and just have a LED ring around corresponding encoder, the value itself is the only important change, and not even every value change (rings have limited numbers of LEDs). So when FX is changed, that is not important for that case. If you display the parameter name, the name is important. Still FX is not, f.e. if both have "Output Volume" as the first parameter. But if you do something plug-in specific, f.e. checking the first parameter of particular plug-in, you want the monitor is triggered on plug-in change, even if the name and value stay the same. AZ Controller tend to "better trigger more then less".
In our current case, first it detects "the parameter is not there" and only then it detects "the strip FX list is changed" (topology change). I can try to "merge" this particular case, but there still can be cases when it is triggered.
If you want avoid informing the device, establish some Set and change its state when "interesting" changes happened. Then monitor this Set changes and send from there or send after checking the change is "significant" in the original monitor. I have used both approaches in different cases (f.e. separate monitor will be triggered on load, while you need to specially be prepared for that in the original monitor. But separate monitor is more "coding", so it all depends from desired logic).
Or ignore duplicated messages on device side (for these messages only... long time ago I was thinking about "filter out duplicated messages" in general, till I have realized in many cases device want receive duplicated messages since they have meaning, f.e. 'the connection is alive', 'LED must be on' in case device auto-off it when a button is pressed, etc.).
Note in case you have timing problem, there is "Min cycles between re-trigger" option for monitors. So it will be triggered the second time, but only after specified delay.
PS. conditions in logic for "Monitor" Action are almost always bad idea in AZ Controller. Exception is f.e. "Device:offline", so you don't want it is checked/triggered at all till you establish connection.
In addition, "Selection:Valid" is always cached (optimistic) since it is not yet known what you want to do with it (name, value, container, etc.). It is "invalidated" by an attempt to really access parameter property in question, f.e. by Monitor itself.
Hi Alexey
Thanks for the information and advice which is really helpful.
A change of track slot IDENT value has big implications; it is used to trigger a full Monitor RST (although I do this in stages) so, with current PIC software, the duplicate message disrupts that process and causes mapping errors (between Sonar/AZ and the PIC).
I think for the instance where an FX Chain is deleted there may be a way to deal with the duplicate message within my PIC software. A possible solution is to look only for received message value changes when an 'IDENT' message value is received. So I mean, if a track slot currently has value 'x' stored in my PIC then I will ignore the incoming message (for that track IDENT) if it has the same value 'x'.
I need to think some more about whether this would work when the order of tracks is changed within Cakewalk. So, for example, moving the Cakewalk track currently in slot 15 to slot 2 causes the IDENT value received for all tracks 2 to 15 to change. My current PIC software deals with but I need to think about the implications of receiving multiple duplicate messages during that message stream which the change of track order instigates.
It will be an interesting challenge to make this possible and for it to be robust.
I will update when I have done some more work on the issue.
Best regards
Robert
Hi Robert,
I have uploaded new test version. It should produce less "re-triggers", in particular it should not re-trigger on FX removal. May be that can help you at the moment. But as I have written, AZ Controller tend to trigger more then less and that is going to stay.
For tracks... Cakewalk has some "integer IDs" for strips. I don't know how stable/persistent they are, I mean may be they stay the same after you re-arrange tracks. These IDs are not used anywhere and there is no other functions except getting it. So I have not exposed them so far. But I can try to add that, so you f.e. can send SysEx with ID (from text) and later somehow you it for matching. Sure, we will have to check how stable they are, if not, that will be useless...
Alexey.
Hi Alexey
I have done some updates to my PIC code to trap the duplicate messages. My first testing session has gone very well and I am reasonably confident that it will be reliable. I will do more testing over the next days.
Thanks for producing the new test version.
I'm running V0.5r11b424 at the moment, which I guess is quite old now.
Are there any other changes to updating to azctrl_0_5r12b426M.exe that I should be aware of?
Regards
Robert
No, there is just new Bit action in r12, but it should not interfere.
Hi Alexey
I have tested azctrl_0_5r12b426M.exe and the duplicate message outputs, when an FX Chain is deleted, have stopped. I will leave the duplicate message trapping in my PIC code as there is no downside to do the checking. It only checks for duplicate messages for the FX Chain 'ident' messages, so it has no implication for speed sensitive messages such as fast fader moves.
Question: Is there any message speed processing degradation due to your message duplication checking in the latest AZ version?
Re: 'For tracks... Cakewalk has some "integer IDs" for strips.'
I have to use the FX Chain facility for a second purpose, that is for the External Audio Inserts which derive the Cakewalk track sends to my analogue mixer (via D/As). It is convenient to have these sit within FX Chain Presets due to the custom name feature.
However I would be interested to test the "integer IDs" if you want to expose them, as you never know what the future of Sonar holds!
Best regards
Robert
There can be some processing speed "degradation" with new checks added. I re-enumerate strips FXes/sends two times instead of one (the first time when "a problem" is spotted, the second time when Cakewalk inform me something is changed). But in practice that can only happened when parameter "disappear", so not during usual operations.
I will keep in mind "integer IDs" for the next time I update the code.
Thanks Alexey.
The latest version is running fine and I have no problems during latest testing.
By the way, I am planning to update from Windows 10 to Windows 11 next week. Is AZ Controller running okay with Windows 11?
Regards
Robert
I have Windows 11 on my primary computer, since long time.
Thanks Alexey
Hi Alexey
I'm still running AZ Controller version azctrl_0_5r12b426M.exe
Have you done a further 'full' release with the duplicate messages fix incorporated or should I stick to the current release I have?
Regards
Robert
I have not "released" updated version, so please continue to use 426M.
Thanks Alexey