AZSlow

I started to work on integration of TASCAM DM24 console with Cakewalk.
I was hoping I can do this with AZ controller.
The DM24 uses MMC protocol for transport controls.
Simple commamnds like PLAY or STOP are not a problem.
However, I am struggling to implement track RECORD ARMING command.
The MMC command for this uses bitmap to identify track that should be armed for recording.
DM24 also awaits response from Cakewalk that the command was successful, such response is a MMC response, and part of it is the same bitmap as in the MMC command.

How do I:

1. Interpret the bitmap so that I can REC enable corresponding tracks in Cakewalk?
2. Send the same bitmap back to the DM24 console?
3. Construct and send to the DM24 new bitmap if user changes the rec enable status of a track using mouse in Cakewalk?

MMC messages are just SysEx messages.
I could use the SysEx action in the Logic tab,
but I need to construct the message based on the previous state of the bitmap.

Also, how do I define action when a user changes track enable status in Cakewalk?
I need to catch such event, update the remembered track bitmap, and again construct a SysEx message using that bitmap and send it to the controller.

For this I would need some variables to store the bitmap, som math functions to modify it,
and some way to include the variables in the outgoin SysEx messages.

Is this somehow possible?
If not, any other idea how to implement track arming functionality with MMC protocol?

Thank you very much

Well... possible, but tricky. AZController doesn't support normal math. But if you don't want write C++ code and HUI emulation of DM24 is insufficient for you, you can try.

a) you need to choose correct "SysEx key length" (Options tab) before assigning SysEx with bitmap parameter, so you have just one control (key length must be equal to fixed part), see "Incoming SysEx processing in AZ Controller" in the manual.
b) "Value from SysEx" action will set "MIDI Value" to one of the bytes
c*) then you can use "Value: x" condition to do things... 128 times you will need to repeat a set of actions to set/unset 7 "Record arms". And that is only for the first 7 channels  8) Doable, but not realistic
c) it is possible create a "Software State Set" with 128 States. And it is possible to create 7 such sets, for each bit. The labels will be just 0 or 1, indicating if ordered State number has particular bit set. F.e. for bit 0 States will be 0,1,0,1,0,1,0,1... 128*7=896 states definitions will take a while, but that takes realistic time (I guess under one hour)
d) using "Set state" "<Map MIDI value>" + "Text" "State of... + "Set state" "<by text>" for yet another Set just with 2 States, will have usable "set"/"not set" for particular bit.

For each channel you need a Set which monitor current value of Record Arm. When you receive SysEx, you check if decoded bit match current state and if not toggle Record Arm. "Feedback" is from monitoring, you construct corresponding "value" based on current states of "Record arm". Yes, 128 actions with conditions per byte...

Is all that worse the result? That is a good question  ;)

PS. apart from "decoding" and "encoding", operations are usual in AZController (and other solutions). And they have to be done properly, f.e. sending feedback just one time on any number of arming changes (per monitoring cycle). I am not ready to spend 1-2 hours to provide an example implementation for the moment, but may be later... Also it is possible to add "&" to "Compare" action, for bit comparison. That can avoid 896 states definitions ;) 

I have considered to implement Bit Action.
Can you give me exact MIDI (SysEx) message you get from DM24 when you record arm let say strip 2 and then disarm it? You can copy/paste from the "Last MIDI event" in AZ Controller.
I will provide (hopefully working) example then (and test new Action really work).

Hi AZ,

I do not want you to put a lot of effort into this unless you consider it useful.
DM24 is an old machine, probably not many still using it.
It uses MMC standard, but that standard is not used much in todays controllers.

Anyway, here are some samples of the MMC MIDI communication DM24 is sending.
For REC arming, it has two modes - STANDARD and MASKED.
In STANDARD mode, a bitmap is used to by controller to set the track arming states at the controlled device, and a bitmap is also used to report track arm status back to MMC controller.

For example, arming track 3 when 24 tracks are defined to be operational:

F0 7F 7F 06 40 07 4F 05 00 01 00 00 00 F7

The actual bitmap starts after the 05, which defines the length of the bitmap.
The 5 bytes in bitmap are called r0-r4 (max can be r13), and the meaning is following:

r0 is special, only contains two tracks bit 6 = Track 1, bit 7 = Track 2,
r1 bit 1-7 = Track 3-9
r2 bit 1-7 = Track 10-16 ...
r3 bit 1-7 = Track 17-23
r4 bit 1 = Track 24

In a 16 track setup the message would look like this:

F0 7F 7F 06 40 07 4F 03 00 01 00 F7

The response from the controlled device to this message confirms the tracks that are armed.
It looks like this:

F0 7F 7F 07 4F 0E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 F7

The bitmap starts after 0E, which is once again byte count of the bitmap.
This is a response from Cubase (which I used to reverse engineer MMC as it natively supports it), I do not know why it posted so many tracks, but it seems that the DM24 doesn't care much about the response content other than it needs to get one, otherwise it will declare the MMC connection as not alive.

I am pretty sure it would be OK if the response would have the same bitmap as the request, e.g.

F0 7F 7F 07 4F 03 00 01 00 F7

So this is this the standard mode.

You can also setup DM24 to use the MASKED mode, which send one message per each track when REC button on the track is pushed.
It looks like this for track 3:

F0 7F 00 06 41 04 4F 01 01 01 F7

04 is byte count
4F is the command code
first 01 is the byte in the bitmap (see above) we are setting, 00 would be r0, 01 means r1
second 01 is a bitmask saying which bits we are setting, in this case bit 1
third 01 is the actual value of the bits, in this case bit 1 set to 1

More than one bit in a byte could be set this way at once

The response from the controlled device is identical to STANDARD scenario, no masked mode there.

This is all well documented here:

https://drive.google.com/file/d/1NUF12R4tffahZprTI3TVE6sUY373y17Q/view

The bottom line is, the SysEx messages used by MMC may have different lengths, even the same command can have different length messages depending on the situation.
So I am not sure how this fits with your SysEx key length parameter.

I don't think this is worth your effort just because of the DM24, I have found a solution using a MIDI translator tool, I will be interpreting MMC commands and sending corresponding MCU commands to Cakewalk, and vice versa, which works fine.

Best regards
Martin

Hi Martin,

I have already implemented Bit Action, I just want test it a bit more before publishing. I will orient an example preset toward 24 tracks STANDARD mode.
I guess it will not work out of the box since I have no possibility to check on real device, but I will write a short explanation how all that works, may be you will be able to play/adjust it then.

Bit operations can be useful for other cases, so thanks for suggesting, even in case you will not use AZ Controller.

There are several AZ Controller presets for Digital Mixers. Even so all mixers support a part of Mackie/HUI and MIDI, using that with Mackie/HUI DAW plug-ins is sub-optimal. When using original protocol is an option, that usually provides more functionality and flexibility. But the time required to create full scale preset is significant, especially without device in hands, so I have stopped writing such presets on my own.

Regards,
Alexey.

Great!

Once you feel ready to publish it I can help with the testing on a real device,
or send you some messages you could use for testing.
Also, if you manage to get track arming working, with some help from you, I could try to implement full DM24 MMC preset for Cakewalk,
including transport keys and jog wheel.

One more thing, to integrate with the DM24 it would also be needed to cover the communication from Cakewalk to DM24 (if user changes track arm status in Cakewalk), e.g. generating the bitmap based on the current state of REC buttons in Cakewalk.

Also, I would like to mention that DM24 always sends all the tracks in the bitmap, not just the last one that generated the message.
DM24 keeps track of what is enabled internally.
So the new bitmap will need to be either compared with the previous bitmap state and send just the changes, or always send all 24 tracks (enable or disable) to Cakewalk.

Another thing to consider, on DM24, maximal number of tracks that can be controlled on one MMC device is 24.
If I want to control 32 tracks, I need to setup two MMC devices, one for tracks 1-16 and one for tracks 17-32.
In that case each device gets its device ID,
so the MMC messages instead of starting with F0 7F 7F will start with F0 7F id

Track 1 (request and response)

F0 7F 00 06 40 05 4F 03 20 00 00 F7
F0 7F 00 07 4F 0E 20 00 00 00 00 00 00 00 00 00 00 00 00 00 F7

Track 17 (request and response)

F0 7F 01 06 40 05 4F 03 20 00 00 F7
F0 7F 01 07 4F 0E 20 00 00 00 00 00 00 00 00 00 00 00 00 00 F7

So bitmaps are identical for track 1 and track 17,
but the MMC device ID is different (00 for tracks 1-16 vs 01 for tracks 17-32)

One last note, what I named STANDARD mode is actually called TRUE mode on both DM24 and MMC specification, sorry for that.

Best regards
Martin

Please download AZ Controller 0.5r12, it has "Bit" Action.

I attach a test preset. It will not work out of the box with device, you need at least unset "loop" flag in Feedback/"_Send RecArm MMC"/"SysEx end" (last Action in this Feedback, explained in the following).

This preset is for "24 tracks" mode.

---
The first control is "_init". For the moment it just indicate with which 24 tracks in the project your device will work (WAI). You can move WAI (by mouse/response from device). It is better define controllable number of channels as the number of physical channel controls you have (faders/buttons/knobs) and move that range logically inside integration, not try to "generate virtual controls" on device (f.e. by defining multiple MMCs).

Even so this example is for 24 channels, DM-24 has 16+1 strips, 16 channel mode is more "natural" for it.

---
From the _Test control I send MIDI(SysEx) messages (loop mode) with "Play" button, I don't have real device and that is convenient for tests (without using any extra software). Looped MIDI/SysEx/OSC are processed the same way as external.

---
I will start the explanation with monitoring. We need to know actual values for all DAW parameters we are going to use for Feedback (sending information back to device). In all DAWs, for almost all parameters, that is done by pooling. Once in a while an "idle" method of integration software is called, which check for changed in interesting parameters. By default Cakewalk is calling the method every 75ms and that is reasonable value (btw you can change it in Cakewalk preferences). AZ Controller can check parameter changes not every cycle, for performance reasons, but in this preset we will check every cycle. Don't worry, on modern machine performance impact is hard to notice till you monitor 10000+ parameters every cycle (DAW is doing way more calculations, with interface buffer period of 2-20ms)

For some monitoring, like transport state (f.e. device has an LED under Play button), we don't have to "save" anything explicitly in preset. AZ Controller does it's black magic internally and we just need to define what we should do once there are changes (normally just send corresponding MIDI message). And some information is "saved" internally in any case (f.e. Transport, saved and available in preset logic).

But for our case we need to collect all "Record Arms" for channels in question, to construct one single SysEx for all of them. Also we don't want send 24 SysExes when we change controlled tracks/load project/etc., so we should schedule sending after all channels are checked (and do that only in case there was at least one change).

Current RecordArm status we can save as "Disarmed"/"Armed", but to simplify other parts in the preset, I have defined "_Ch"(annel) Set with "1..24" possible States (note, as in most parts, real numbering is started with '0' (zero) and State names have no special meaning, I can rename them as "Channel0","Channel1" or "Cat","Dog",etc, that will not change anything). Then I have defined "_RecArm(_Ch)" as dependent from "_Ch", so effectively that is an array of 24 variables (with "_Ch" as an indext, and again, name of the Set has no meaning, could be "_RecArm", "RA(X)", etc.).

----
To fill Record Arm status from Cakewalk into "_RecArm(_Ch)" array, in AZ Controller separate "Monitor" for each parameter must be defined. I have defined "_RecArm(_Bit)_ChX" controls for each channel (why it has "(_Bit)" I will write later). These controls are the same, except the first statement ("Set _Ch"). The rest is that _Ch dependent, so identical.
I select parameter in question (in this case "Track 'WAI + Ch' Record Arm") and then define "Monitor" Action.

Monitor will monitor "parameter value" (Record Arm), every idle cycle ("Ultra" speed), with priority "1". Relative priority is important, we need SysEx sending "Monitor" executed after all parameter monitors, otherwise there can be mess.

Actions in Monitors are defined in "Feedback" tab, here is the logic:
* set "_Bit" (2 States Set) to '0' (next Action can fail if we don't have sufficient number of tracks...)
* map parameter value to "_Bit" (that is done uniformly, all parameter in Cakewalk have discrete or continuous values between 0. and 1.). If that fails, "_Bit" will stay as '0' from the previous Action.
* we compare (by position, NOT label) "_Bit" and "_RecArm(_Ch)" and in case there are the same (Action was Successful) do nothing ("Final" flag). Note that "Final" is ignored if Action failed, so execution continues in case positions of these 2 "switches" are different.
* we toggle "_RecArm(_Ch)", we know it should be changed and there are just 2 States. Note "Set engine state" flag, Monitors use duplicated local variables by default (f.e. we have set "_Ch", but that change will be discarded after Monitor is Checked/Triggered. Well... we will use the very same "_RecArm(_Bit)_ChX" controls for other purpose later, and that very same "Set _Ch" Action will really change "_Ch"... tricky, I know).
* finally we "Reset" (trigger) SysEx sending Monitor. It is the same for all channels and has lower priority (5), if at least one track Record Arm was changed during current cycle, SysEx sending Monitor will be called at the end.

We have all information we need to construct Record Arm MMC feedback and SysEx sending Monitor will be executed in case there are changes.

-----------
_SendRecArmMMC control has "Timer Once" monitor only. "Timer Once" means it is executed only one, on explicit request (Reset), but logic is from "Timer", so something triggered unconditionally (Parameter Monitor will not be triggered till monitored parameter or value are changed, even so it can also be triggered explicitly by Reset). Priority 5 is lower then Parameter Monitors priority 1. Exact numbers are not significant (there are situations when 3 or more Monitors should be checked in predictable order, that is why "priority" is not just "low" and "high")

In the Feedback part I construct SysEx, starting from fixed portion and adding bytes. Here the functionality of setting "bits" has significantly simplified the implementation. I work with the "_Value" Set with 128 States (may be not the best naming, I also use "Value" System Set with current MIDI value, just notice they are different).


Note "Loop" flag for the last Action. You need unset it when working with real device (you no longer see sent message then, in the "Last MIDI Event", but your mixer should get it).

------------
We need SysEx processing, MMCArm Control. That is the only control which react on external device in this preset. Here fixed length of SysEx in the Options tab is imported when (re)assigning. What AZ Controller currently think is fixed part (for already assigned controls the length is control dependent) is clearly indicated in the "Last MIDI event".

The rest is mapping from SysEx bytes ("Value from SysEx" Action, with explicit dynamic byte index specified) to "Value" System Set (don't forget it is different from "_Value" I have used before).
And for each (interesting) bit, I put it into "_Bit" set, and call related control.

And here is a trick... the Control is the same I use for monitoring. Logically, we monitor and set exactly the same DAW parameter. Parameter selection logic can be lengthy, in this particular case that is just one Action, in complicated solutions like MCU there is a huge tree of actions (one MCU physical control always sent one MIDI message, but it can be used for 20-30 different parameters). To not duplicate it (error prone) nor put into yet another Control/Function, I just reuse the same control.

It works because during monitoring execution stops on corresponding "Monitor" Action (can be several in one control), while during normal execution (from MIDI assignments or in calls) "Monitor" Action is ignored.
When called from MMCArm, Monitor Action will be ignored, but everything will be executed (except interruption with "final" flag on successful Action). While during monitoring, Actions after Monitor are not even looked.

Starting the same way as for Parameter Monitor (set "_Ch", choose proper Track Record Arm), we toggle parameter when saved "_RecArm(_Ch)" is not the same as "_Bit". I could use "final" in Compare Action, but this time I have used "Last action:OK' condition (more to demonstrate that possibility).

Note we do NOT change "_RecArm(_Ch)" there, it will be updated in monitoring. Cakewalk and other DAWs don't change most parameters immediately, up to the fact if you immediately ask DAW current value after setting it, the DAW still returns old one. That sometimes produce fancy unexpected problems and AZ Controller partially workaround it, but saving in monitoring only has other advantages. F.e. you don't really know if DAW is able to record arm particular track in particular situation (f.e. during playback, may be track doesn't exists, etc.) and so "predicting" what will happened is more complicated then just checking what has happened.

Finally, note I don't force "reply SysEx". If there is no changes in the DAW (f.e. you have tried to arm not existing track), no reply will be sent (no changes). To force reply, you can Reset sending Monitor, the same Action as in Parameter Monitors. The execution will happened in usual for monitoring order. You can set Reset "as next" (or with even longer delay) instead of "now".

---------------

Writing this description took several times longer then creating the preset. And I have not even commented MMC. I hope that is somehow useful.

I have tried to find what DM24 can send, but I have not found much apart from video about Cubase.
And from that video (and related blog) it is only clear faders/mutes can send/receive something, in 3 switchable on the device banks. What is with Select buttons and pan knob is unclear. I guess whole MMC section send something. If faders can send separate "touch", that can be bonus. The same if EQ section is MIDI capable.

BTW Mackie plug-in in Cakewalk doesn't  work with track and buses at the same time and you need more then one instance for more then 8 channels. AZ Controller doesn't have these limitations. I mean you can implement what is shown for Cubase, some tracks + buses with switching from the mixer.

Great, thanks. I will try to test it tonight.

Yes, 16 tracks are more natural for the DM24, and also that is the only way I can control 32 tracks.
That is how I do it now with the MIDI translator tool.

Yes, I have noticed I can probably not control master section with Mackie in Cakewalk, which is a shame,
as the DM24 also has master fader layer.

Yes, I am using 4 instances of Mackie units (Main unit and three extenders) to control 32 tracks,
deciding to which MID port/MCU Unit the message goes in the MIDI translator tool logic.

Yes, it would be great if I could do all this with AZ Controller alone.
If not, I can still use a combination of AZ controller and the MIDI translator tool. In that combination I could definitely do anything, but it would be nice if AZ Controller could handle all the logic.

No, there is no documentation available on what exact MMC messages does DM24 send/expect.
I have collected the relevant messages from scenario where DM24 controls Cubase, as Cubase supports MMC out of the box. It does not support JOG wheel, however, but I figured how to make JOG wheel work as well.
I can send that file to you in the afternoon (Europe time zone), no problem.
It is just my internal notes, not intended to public, so probably not very clearly written, but I can explain everything.

As for what controls are being sent over MMC and/or standard MIDI from DM24, it is the following:

1. Transport controls over MMC = PLAY, STOP, REC, FFWD, REW, JOG WHEEL
2. Track arm control buttons over MMC = 16 buttons in two banks for 32 buttons altogether
3. There is also an ALL-SAFE button, which send a short two byte bitmap of all zeroes meaning all tracks sshould be unarmed. After the ALL-SAFE button is switched off again, DM24 resends track arming massage with all the previously REC enabled tracks in the bitmap. So more that one track status can change with one MMC message.
4. Fader movements over standard MIDI CC (7-bit precision only, so must be recalculated to 14-bit pitchbend messages used by Mackie), fader 1-16 send CC on MIDI channels 1-16, different CC# for different fader banks, and can be freely configured on DM24
5. Fader do not send touch/untouch messages, so again some logic trick with state variable and timer is needed to block the feedback from DAW when operating faders, also not rack selection by faders is possible
6. PAN pot over standard MIDI CC 7-bit, also configurable. There is just one pot, what it send depends on which track is selected (SEL button pushed)
7. MUTE buttons over standard MIDI CC, configurable
8. In the master section there are three more buttons dealing with enabling monitoring back from the recording device, two of the send MMC messages, one does not send anything, maybe it is state dependent, I do not know. So these two buttons could be used for anything, like bank change for example, if needed. Or maybe even for the original purpose, but I do not have a use case for that just yet.
9. There is a SOLO switch, that transforms MUTE buttons to SOLO buttons, but unfortunately neither that switch nor the SOLO buttons send anyting over MIDI. This is a shame.
10. MTC - DM24 can send and receive standard MTC. Maybe there i also some GOTO functionality, but I have not tried yet. DM24 does have built in automation, but I never used that.


In addition to that, there is additional MIDI mixer layer with 16 faders, mutes and pans that could also be used for something. This layer does not influence any tracks on the DM24, just sends MIDI messages. This layer also has possibility to control PANs with four rotary dials beneath the display, so 4 consecutive PANs can be controlled by 4 independent pots. I am not sure if the same can be done with the standard fader layers, probably yes, I have to doublecheck.

Instead of MIDI mixer layer there is also possibility to select Mackie HUI emulation layer, but this only suports 8 faders for volume control.

Also, a MIDI faders layer and MIDI Controllers leyer exsit which can be used to control arbitrary MIDI parameters

There is also some bulk MIDI messages functionality for storing and restoring DM24 presets over MIDI.

And that is more or less it I guess as far as MIDI posibilities of DM24 go.

As for all other buttons in the master section of DM24, their purpose is documented in the DM24 user manual on page 87.
There are location memories, REPEAT play and other things. I am not sure if these functions work with MMC or just with DTRS, but I can try.

https://tascam.jp/content/downloads/products/299/DM-24_manual.pdf

Also, on page 93 there is a description of MIDI Controllers and MIDI Faders functionality.

That is the original manual for the initial firmware of the DM24.
There are some new feaures in firmware 2.0 and 2.1 respectively.

Here are manual addendums for newer firmware versions

https://tascam.jp/downloads/tascam/299/dm24_release_notes_version2.pdf
https://tascam.jp/downloads/tascam/297/dm24_v21_en.pdf

In version 2.0 the MIDI Mixer layer was introduced, see page 19 in version 2.0 release notes.

Some comments, numbering is preserved.

1. unfortunately MMC are "commands", unlike normal MIDI controller buttons which send "pressed" and "released" separately. So no "Shift"/"Ctrl" logic, only "CapsLock". Play/etc MMC are fixed messaged, so simple to configure (just don't forget to set SysEx length to cover whole message when assigning). If you want "reply" example, I mean if there are LEDs or reply is expected, I can create one. I have not checked MMC Jogging, but I can make an example as well.
2. MMC Arm example is already there. Sure it requires some tuning and may be extending to 2 banks (since there is a dedicated bank switch, 32 tracks mode make sense.
3. may be ALL-SAFE can be used for something else. Duplicated rec-arm message will not change primary logic.
4. In AZ Controller you can use CCs directly to set volume.
5. Touch logic can be tuned. It depends on Mixer behavior when you operate it and some message is received. If faders are not "fighting" with fingers in this case, nothing should be done (usual monitoring which sends changes all the time). In case of fighting, monitoring can be suspended for a while in case fader is manually operated (can write an example).
6. if "SEL" buttons are not sending anything and don't respond to messages, only corresponding pan is possible to configure on the DAW side.
7. So as faders, just for other parameters (and for sure without fighting problem)
8. any "extra" buttons are helpful, f.e. to logically switch Mute to Solo, etc.
9. it is clear not all controls can be used for DAW.
10. it is better not mess with MTC or other time codes. DAWs are traditionally buggy when they are not time masters and syncing from the DAW can trigger side effects in the mixer.

Extra layers which send MIDI are good, especially when you want use mixer as mixer in parallel. HUI is better avoid when using AZ Controller, less logic on mixer side is better.

Storing presets is not useful for DAW controlling purpose.

I am trying hard to implement the ALL SAFE button on the DM24.
The problem is that ALL SAFE on DM24 (for a reason I do not know) sends two identical messages instead of just one. As processing of the RecArm actions takes about 2 seconds when 16 tracks change state in one MMC message, there are some strange race conditions happening, receiving the second message while still processing the first one makes no good.
The MMC message(s) AL SAFE sends when activated is

F0 7F 00 06 40 04 4F 02 00 00 F7 (Regardless of how many tracks I control)
F0 7F 00 06 40 04 4F 02 00 00 F7

As this is a fixed message which does not change, I have implemented a deduplication of such message, and create a standard REC ARM MMC message from the Logic tab (with all zeroes in bitmap and with loop activated), and let your RecArm code disable all the tracks.
This works fine.

But the same problem arises when I push ALL SAFE again to re-arm the tracks that were previously armed.
DM24 sends two identical track arm messages, and the race conditions apply again.
So I need to deduplicate this as well, but I don't know how.
Is there any way of how to block another RecArm message while the first one is still processing?

Thank you very much

In case you want disarm all tracks (and you don't care that also disarm tracks which are not in the current WAI), you can use "Function" "All" "Tracks Disarm" Action instead of disarming one by one.
That will not decrease the time Cakewalk needs to disarm, for some reason it always take a while...

For "deduplication". There are 2 approaches. If you know some fixed messages is always duplicated, you can ignore every second receive. Create a Set "AllSafe" with "First" and "Second" States, and at the beginning of the message processing insert Actions:
"Set state" "AllSafe" "<next>" "loop"
"AllSafe:First" - "Undefined" "final"
So, toggle State and every second time do nothing.
Note you better not define Monitor actions in such Control, since "AllSafe" will influence monitoring then.

The second approach is timer based, create a Set "AllSafe" with "Idle" and "InProgress" States. Add a Timer Monitor (Once), in which you "Set state" "AllSafe" "Idle" "set engine state". And in processing
insert:
"AllSafe:InProgress" - "Undefined" "final"
"SetState" "AllSafe" "InProgress"
"Reset" "...::your timer" "after X seconds".
That will prevent re-triggering during X seconds after you have started processing.

Quote from: azslow3 on April 03, 2025, 12:22:25 PMThe second approach is timer based, create a Set "AllSafe" with "Idle" and "InProgress" States. Add a Timer Monitor (Once), in which you "Set state" "AllSafe" "Idle" "set engine state". And in processing
insert:
"AllSafe:InProgress" - "Undefined" "final"
"SetState" "AllSafe" "InProgress"
"Reset" "...::your timer" "after X seconds".
That will prevent re-triggering during X seconds after you have started processing.

Hi, with the timer base approach, I was reading in your documentation that states are local to Feedback actions rather than global. So, will such AllSafe state be shared between two different feedback actions?

During monitoring, current State of a Set is initially copied from global one  (called "Engine state"). So, till changed, current State is the same everything. But any changes in Feedback are local by default, till "set engine state" flag is set.

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.


 

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.

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.

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.

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

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.

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!

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

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.

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.

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.

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.

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

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.

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. 

One more thing I have noticed, I am sure you will have explanation.
When Transport Stop action is performed, Cakewalk sends out plenty of CC messages.
I believe it is done by Cakewalk, not the AZC, as it is being sent to all active MIDI outputs,
not just the one used by AZC.

And yet another question.
Transport Stop action not only stops playback, but also returns the play head to the beginning.
I would like to implement a dual stage Stop action, where pressing Stop button first time while Playing/Recording
would stop transport, but stay where it is in timeline (probably more Pause than Stop),
and only second press of Stop button would perform a full Stop Function and return to the beginning.
However, I don't know which function to use for Pause.
I have seen there is Play/Pause command, which I guess is a toggle between Play and Pause,
but I prefer not having a toggle. Can you please advice Function or Command for Pause?

Thank you very much

Quote from: mgr on April 16, 2025, 01:55:07 PMOne more thing I have noticed, I am sure you will have explanation.

:)

QuoteWhen Transport Stop action is performed, Cakewalk sends out plenty of CC messages.
I believe it is done by Cakewalk, not the AZC, as it is being sent to all active MIDI outputs,
not just the one used by AZC.

It is for "real" MIDI devices. Controlled by "Project/MIDI/Zero controllers when play stops" option.
You can set "Block all channel messages" and "Block all SysEx messages" in AZ Controller Options.
From what I remember, in this case Cakewalk will realize that your device is just controller and will not send anything there (even when enabled in Cakewalk preferences)

QuoteTransport Stop action not only stops playback, but also returns the play head to the beginning.
I would like to implement a dual stage Stop action, where pressing Stop button first time while Playing/Recording
would stop transport, but stay where it is in timeline (probably more Pause than Stop),
and only second press of Stop button would perform a full Stop Function and return to the beginning.
However, I don't know which function to use for Pause.
I have seen there is Play/Pause command, which I guess is a toggle between Play and Pause,
but I prefer not having a toggle. Can you please advice Function or Command for Pause?

There are several related commands (easier to search in Cakewalk keyboard bindings, since there you can really search...). Some are affected by options like "On Stop, rewind to Now marker". For fine control you can use "Function/Transport" Action.

Do decide what to do in particular situation, use "Transport" and "Pause" Action Conditions for required Actions. F.e:
* 'Pause:On' - Function/Transport/Play OFF
* 'Pause:On' - Command 'RTZ'
* 'Transport:Play' - Function/Transport/Pause
Will pause when playing/recording and stop with rewind when paused.

Note Cakewalk reports some combinations of transport and pause not intuitive way (that can be version dependent).

Thank you very much, will try those.

One problem is, that the DM24 sends out combination of Stop and Play MMC commands when I press Play. I have no idea why it does that, but it effectively means I have to somehow filter out the Stop part of the Stop/Play message combination, but I do not know what is the most effective way to do that, given that I also need to implement isolated Stop messages.

I need to wait for a (very) short time after every Stop message to see if Play message arrives, and if it does, treat it as Play, otherwise treat it as Stop.

So one idea is:

1. Stop message arrives, I set a WaitingForPlay state to Yes, and start a short ontime timer, but perform no Action.
2. Play message arrives, I set a WaitingForPlay state to No, and perform Play Action
3. In Timer feedback for Stop, if WaitingForPlay is Yes, I perform Stop Action, otherwise I do nothing

Would that work?

During 3, you can't Stop from timer directly. That is the case when you need to "send loop" something (I propose OSC '/stop' with value 1) and define "real" stop Control assigned to this OSC.

Quote from: azslow3 on April 16, 2025, 03:22:48 PMDuring 3, you can't Stop from timer directly. That is the case when you need to "send loop" something (I propose OSC '/stop' with value 1) and define "real" stop Control assigned to this OSC.

I suspected that, OK, so I will loop then, got it.

OK, so everything seems to work as intended, including dual-stage Stop button (Pause on first press, Return to Landmarks on second press).
So 32 tracks are covered.

Things to do next:

Implement SOLO, meaning using the MUTE buttons for SOLO function. DM24 has a switch for this,
but it does not send any MIDI, and neither are the MUTE buttons in SOLO mode,
so I have to come up with something to switch between MUTE and SOLO.
There are at least two buttons that send SysEx that I have no use for yet, so I will probably use one of those as a SOLO/MUTE switch.

Also, it would be nice to be able to control even more channels with some sort of bank switching. I could use the other unused SysEx button to switch the banks, but I need to understand how to do this in AZ Controller. I am sure you have some bank switching functionality there. :-)

For switch, toggle some State, f.e. "SoloMode" "Solo"/"Mute". Then you need to duplicate "Strip" Actions in the corresponding controls, change one to Mute and add "SoloMode:xxx" conditions to both.

For banks. Current setup is WAI based. You can move by mouse or call "Strip" Action to selected desired new first strip (f.e. WAI + 16) followed by "WAI" Action to set new WAI region.

Thank you very much.

I will also have to make the lights on DM24 buttons reflect the bank switch.
For WAI shift I need to query the state (REC, Mute, Fader, Pan) of the newly selected channels and update the DM24 to reflect that.

For the Mute/Solo switch, I will need to query the Solo state of every channel and send that to DM24's Mute buttons when I switch from Mute to Solo, and query Mute states when switching back to Mute.

When lights are as desired for current channels, they should be ok after WAI is moved.
As I have written before, well made preset for AZController  does that automatically. When you move controller channels or change controlled parameter, corresponding Monitors will re-trigger and send feedback.

I have another question.
DM24 can store up to 10 timecode location points and send MMC LOCATE commands when I press DIRECT button and a number (0 to 9).

If I understand it correctly, AZC does not implement GOTO command that would set cursor to some absolute time.

So I guess I would need to use mouse to set location points (markers) in Cakewalk, and manually set the 10 location points on DM24 to some well known timecode values, and use those to move to Cakewalk location points.
This can be done once and will be remembered by the console after restart.

For example, I could set the timecode presets 0-9 like this:

0 - 00:00:00:00 - go to to marker 0
1 - 00:00:00:01 - go to to marker 1
2 - 00:00:00:02 - go to to marker 2
3 - 00:00:00:03 - go to to marker 3
4 - 00:00:00:04 - go to to marker 4
5 - 00:00:00:05 - go to to marker 5
6 - 00:00:00:06 - go to to marker 6
7 - 00:00:00:07 - go to to marker 7
8 - 00:00:00:08 - go to to marker 8
9 - 00:00:00:09 - go to to marker 9

EDIT: I have already implemented it like this, it works fine and makes sense. I just had to change the timecode values as the DM24 does not send frames, so I used second to number the markers.

You have considered right direction. I had discussions before about a possibility to use absolute time, but use cases are questionable. Markers are project independent.