Math functions, variables, message construction

[mgr]

I see, so that is what the "set engine state" is for. 

So I tried.

I made a RecArming state with "InProgress" and "Done" values.
I test and set RecArming to InProgress when an MMC Rec Arming message arrives in Logic tab.


I set the RecArming back to "Done" in Feedback tab in _SendRecArmMMC timer monitor at the very end, after it sends out the MMC response message.

AllSafe activation works just fine, all the tracks go into Unarmed state.

Deactivation of AllSafe (e.g.) re-arming all the tracks that were armed before AllSafe works as well, but still not 100%.
Sometimes it does not activate all the tracks, just some of them.
I am testing with tracks 1-16, all being Rec Armed.
In cases where it does not work, it only re-arms first n tracks, where n can be any number between 1 and 16.

This is a typical communication in such scenario, AZControl send two or three MMC messages back, one of them is correct, others are incorrect (not all 16 track bits set to 1)

Attempt 1:

491209 - MIDI OUT: F0 7F 00 06 40 05 4F 03 60 7F 7F F7 F0 7F 00 06 40 05 4F 03 60 7F 7F F7
492234 - MIDI IN: F0 7F 00 07 4F 03 60 7F 0F F7 (wrong)
492769 - MIDI IN: F0 7F 00 07 4F 03 60 7F 7F F7 (correct)
493327 - MIDI IN: F0 7F 00 07 4F 03 60 7F 0F F7 (wrong)

Attempt 2:

15222 - MIDI OUT: F0 7F 00 06 40 05 4F 03 60 7F 7F F7 F0 7F 00 06 40 05 4F 03 60 7F 7F F7
15723 - MIDI IN: F0 7F 00 07 4F 03 60 01 00 F7 (wrong)
17810 - MIDI IN: F0 7F 00 07 4F 03 60 7F 7F F7 (correct)

The rec arm status of the tracks in Cakewalk remain the same as the last message indicates, so in attempt 1 result was wrong, in attempt 2 result was correct, but there should not be two messages anyway.

In majority of cases it looks like this, and that is correct

543449 - MIDI OUT: F0 7F 00 06 40 05 4F 03 60 7F 7F F7 F0 7F 00 06 40 05 4F 03 60 7F 7F F7
544000 - MIDI IN: F0 7F 00 07 4F 03 60 7F 7F F7

So, I am scratching my head what have I done wrong, can not figure it out.


 

[azslow3]

Can you attach your current SPP preset?

In theory, intermediate "wrong" (partially armed) results can be explained by Cakewalk slowness. During monitoring cycle some tracks are not yet armed by Cakewalk (it is still in progress, that is asynchronous... also monitoring can be called completely asynchronous since Cakewalk in some situations "forget" to call it at all, f.e. when some dialog is open...). That we can deal with by resetting "send armed SysEx" with 1-2 seconds delay after we detect a change (it will effectively be called after 1-2 seconds without changes since each Reset by default add delay from current time).

But if everything works as I think, the end send status even now should be as desired. Except if sending partial/"wrong" result is triggering new message from the mixer. And in your traces I don't see such messages.

It can be some mistake is in preset or AZ Controller does something wrong. That is the first time someone tries to "restore" many armed tracks, I mean that was for sure not tested before. But I want check that with concrete preset.

[mgr]

I confirm that no additional messages are being sent from the DM24 that could cause the AZ plugin to send multiple responses.
However, as you can see, I am sending two identical MMC REC ARM messages, as that is what DM24 does when I de-select the AllSafe button.


Once I get home from work I will send you my preset.

Also, I will try if your original preset exhibits the same behavior.
It should be the same, as I just use your RecArm action to arm/un-arm tracks.

In my preset I have made some modifications, mostly to make it work for 32 tracks.
I have reduced your RecArm action to only 16 tracks, and made a copy of that called RecArm 1
to deal with tracks 17-32, as those tracks are controlled with MMC Device ID 01
and I could not find a way to process both MMC ID 00 and 01 within one set of Logic actions.

I have also duplicated the _SendRecArmMMC (do not remember the exact name) monitor
creating separate _SendRecArmMMC 1 monitor for tracks 17-32.
(I think this was not necessary, standard Rec arming worked fine with one monitor for all 32 tracks,
but in the process of troubleshooting I wanted to have tracks 1-16 separated even in feedback)

I have also introduced the RecArming and RecArming 1 states with "InProgress" and "Done" values
for the purpose of locking the message processing before the processing of previous message has finished,
as discussed above.

[mgr]

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.

[azslow3]

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).

[mgr]

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.

[mgr]

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!

[azslow3]

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).

[mgr]

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.

[mgr]

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.

[azslow3]

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.

[mgr]

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.

[azslow3]

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").

[mgr]

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.

[azslow3]

One 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.

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?

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.