Update to the Cakewalk API

[azslow3]

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.

[norfolkmastering]

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

 

[azslow3]

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.

[norfolkmastering]

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

[azslow3]

No, there is just new Bit action in r12, but it should not interfere.

[norfolkmastering]

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

[azslow3]

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.

[norfolkmastering]

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

[azslow3]

I have Windows 11 on my primary computer, since long time.

[norfolkmastering]

Thanks Alexey