AZSlow

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.

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

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.

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.

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.

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.

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.

Please visit the documentation section in case you have never installed this plug-in before.

Download it now

There should be no Ads, spies or other nasty parts in this download. The installer does not try to connect to the Internet. If you see such a warning from your OS, stop the installation/use immediately. The DLL can theoretically write a log file into its own folder, but that should not happened with releases. If you turn on OSC in the AZ Controller preferences or load a preset with OSC turned on, AZ Controller is acting as a network server. You can get related warning from your firewall software. Even in this mode AZ Controller does not try to communicate with the Internet, while it will start respond to OSC Clients messages


This is the only place where you can get the original AZ Controller for sure. The license allows coping/distributing it unchanged, but I am not responsible for distributors misbehavior.

Changelog (since 0.5r11)

• NEW: Bit Action

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

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.