AZSlow

OSCII-bot looks promising.
I thought it can only do standard 3-byte MIDI, but now I found that it also support SysEx via oscstr string.
It also has bitwise logical operators, so it might do the trick.

With CSI I don't see a way of interpreting a bitmap or creating bitmap-ed response.
I actually do not even see a way of creating an MMC control that has parameters,
so I guess one could only implement simple MMC messages like Play and Stop that have fixed messages without parameters, as it might be impossible to map MMC parameters to thise expected by CSIs predefined controls.
Maybe I am wrong, I did't have time to get very deep into CSI docuentation.

For MIDI to OSC there is OSCIIbot. I don't know why there is no Python binding for Surface API (at least there was no the last I have was searching), it is not possible support controllers without. C++ API is there and partially simpler to use then Cakewalk one. Also it is complete (unlike for Cakewalk), that means surfaces can do absolutely everything (most operations since Sonar 8+ are barely supported by Cakewalk API).

But CSI is advanced. It may be able to handle MMC (or you can ask to support it).

Well... I wish AZ Controller could work with REAPER. But I still have not converted it.

Maybe I could use the ReaScript API with Python.
I do not understand how to receive or send a MIDI message with ReaScript,
it has many MIDI functions, but I suspect they deal with MIDI recorded on a rack within Reaper
rather then live MIDI input/output messages. But I can be wrong.
Worst case I could use some Python MIDI library to do that I guess.

Honestly, I was thinking about moving to Reaper now that Cakewalk By Bandlab is being discontinued,
but I didn't find a way yet how to integrate it with MMC control surface (other that using MIDI Translator
to emulate Mackie MCU).
All the extensions I found were only supporting "basic" MIDI commands like Notes and CCs.
I was also looking into OSC, but haven't found anything that could convert MMC into OSC,
not even speaking about bit operations.

You are welcome.
Yes, I have tested MMCArm, not (1) (as you can see in _Test SysExes). And what is not tested almost always has bugs.
Timing tuning is always a compromise between user experience and reliable operations.
And Cakewalk is traditionally slow with some operations (f.e. REAPER can record arm 32 tracks instantly, even if you ask that during recording).

So the short story is IT WORKS!!!

I have tested AllSafe with all 32 tracks armed/disarmed at once.

There was one small error in MMCArm 1 when RecArming variable was set to Idle instead of Arming, but I changed it and now it works fine.

There is one drawback, however, that when the timer was set to 1 second,
then after arming single track it took long before I could arm another track.

I experimented with the timer. When set to 2 cycles, track arming worked fast,
but AllSafe was generating once again incomplete messages followed by complete messages.
But everything worked anyway, as the final state of the tracks was correct.

But to avoid two messages being generated, I have settled the timer to 4 cycles, which still gives an acceptable track arming speed for individual tracks, and does not produce incomplete messages at the same time.

So I guess I will leave RecArming and AllSafe like this for the time being, and move on to other MMC functions and faders.

Thank you very much again!

Thank you very much, I will try to understand it and test it.

The loop trick I used as I was not able to do what you did here,
AllSafe as a copy od RecArm with all bits set to 0,
I must have been doing something completely wrong,
it did not unarm the tracks in Cakewalk at all.

My modifications:
1) instead of directly resetting Send monitors on changes (btw you was resetting only the first one, from all 32 channels, which I guess is wrong), I "call" controls (so as a kind of "function") which does that. I have "reused" SendRecArmMMC(1) since they have just a timer, so I add what I want to do (reset that timer) after. Note it will be ignored during timer check (as all actions after monitors) and timer Action will be ignored when the control is called as a function (I have tried to explain how that works before). Also note that functions are always defined as Logic controls, but when called from Feedback, they are executed as actions in them was defined in the monitor (in feedback context).
That give us a possibility to tune the delay quickly, just in 2 controls instead of 32. I set 1 second, but you can try lower values (obviously the indication on Mixer will always "lag" by that delay, so it should be as small as possible, but sufficient to avoid what you have seen as "wrong" intermediate messages.
2) I have changed RecArming(1) sets to have "Idle", "Arming" and "AllSafe". That way we can distinguish what is "InProgress" and react differently. F.e. it can take a while till feedback is sent, especially with 1 second extra delay (after last change in Cakewalk, can be several seconds!). "Operator" can reconsider and press "AllSafe" button again during that time and we should try to react properly.
3) I call SendRecArmMMC(1) in MMCArm(1), to be sure the feedback is sent in any case (even if there was no changes in Cakewalk arm statuses).
4) I have reworked MMCAllSafe(1). Effectively that is a copy of corresponding MMCArm, but "Bit" is always 0 and "RecArming" set to different state.
"Loop" sending from direct MIDI reaction should be avoided for more then one reason. It will be processed in the next "idle" loop and there is no buffer, if you "loop send" several messages before idle loop run, only the last one will survive. Also technically there is never a need for that, you can "call" controls as functions (as I have don in (1)).
"Loop" sending exists for 2 purpose: testing and "simulating" MIDI from monitoring. There are many things which can't be done in Feedback (and if you call a "function" from there, such Actions will be ignored as well).
So the only way is to "send" something to imitate normal incoming message (BTW better use OSC for that, to clearly indicate that is not from real device).
And now you can understand why loop sent messages are not queued and not "delivered" immediately: it is too easy create "busy loops" or "snow balls" with that (I had that several times before introducing such restrictions, that easily crash Cakewalk).

Quote from: Nowell on April 09, 2025, 01:16:16 PMThe master fader currently does not move in either way.

As far as I know, HUI does not have master fader.
So whatever your master fader sends over MIDI is probably not HUI message.
And it is also not MCU I guess, since MCU does not use SysEx messages.

Have you tried transport buttons? Play, Stop, Rec,...?

So I tried to reproduce the problem with your original preset, trying to arm 24 tracks at once.
I can make AZC send two MMC messages back occasionally, but in this case the last one seems to be always correct, so it works.

420683 - MIDI OUT [Bome MIDI Translator 1 Virtual Out]: F0 7F 7F 06 40 07 4F 05 60 7F 7F 7F 01 F7 F0 7F 7F 06 40 05 4F 03 60 7F 7F 7F 01 F7
422536 - MIDI IN: F0 7F 7F 07 4F 05 60 7F 07 00 00 F7 wrong - or better term is incomplete
424511 - MIDI IN: F0 7F 7F 07 4F 05 60 7F 7F 7F 01 F7 correct - complete

So I guess what is happening is that sometimes the monitor does not finish all the tracks before MMC message is send out, but it does so in a "second run" when other tracks' parameters are changed.
And the deduplication I have introduced somehow messes with this second run.

I have attached my preset here as well.