AZSlow

Quote from: mgr on April 16, 2025, 12:51:34 AMOne observation - as I have not found any transport states for FFWD and REW

It is called "FastMove". It is independent because that can happened in any primary transport state.

QuoteWhat's left to do is Faders and Mutes for AUX1-8 and BUSS1-8,
but I am not sure how to assign AZController to those in Cakewalk.
Is that possible?

In "Strip" Action you can select strip type. You are controlling "Track"s so far, but you can also control "Bus"es and "Master". With master I agree with you, better keep it local to mixer in case mixer is used for audio as well.
"AUX Track" in Cakewalk is just a track (with possible input from other tracks). They don't have separate strip type. 

OK, so I have now managed to implement Mutes and Faders for tracks 1-32,
and also Play, Stop, Rec, Ffwd, Rew and dual-speed Jog controls
on top of your track arming functionality.
So far it seems to work reasonably well, but I had no time for much testing.

One observation - as I have not found any transport states for FFWD and REW, I am sending MMC responses to those commands directly from Logic tab, and have no feedback actions when I activate those using mouse in Cakewalk, but it is not a big deal.

What's left to do is Faders and Mutes for AUX1-8 and BUSS1-8,
but I am not sure how to assign AZController to those in Cakewalk.
Is that possible?

As far as master fader is concerned, I am not sure whether it makes sense to control it in Cakewalk, as my stereo mix audio should go back to the DM24 mixer, so I can just leave the master fader in Cakewalk at 0dB and control the volume on the console itself I guess.
But I have to check if I can do the routing on the console so that this stereo return from Cakewalk won't be affected by the 32 channel faders.

OSCII-bot is a nice peace of open source software from Justin (REAPER developer and owner). He knows how to do things efficiently 

The developer of CSI is also friendly. Since you want standard MMC, you can try to ask about it. He can implement it, in case there is no existing ways (and in this case you can get a tip how to proceed).

BTW REAPER has way more active independent developers, all Cakewalk supporters are almost gone (partially changed to REAPER). Also with REAPER you know it will work in 5, 10, 30 years... You can download any single version and it requires no cloud authorization, works on all reasonable systems (including Linux and RPI), and project format is almost self explaining text file. I mean all worries Cakewalk users had since Platinum are void there. Cakewalk still has its advantages, but the difference slowly disappear (f.e. with new take lane system introduced in REAPER 7) and when some feature exists in both, in REAPER it is more flexible, faster and not buggy. Some people prefer Studio One, for more Cakewalk like behavior, but for me it is way more expensive (then REAPER) for almost the same limitations as Cakewalk. And dealing with Studio One projects, it looks like many features are implemented as... more or less face-lifting hacks... Justin doesn't do this (there is no "owner-managers-programmers" relations in REAPER world since all that is just a single person, he works with several other programmers, but he definitively will not ask them to write "a quick hack for new advertisement").

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.