Math functions, variables, message construction

[mgr]

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

[azslow3]

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

[azslow3]

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

[mgr]

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

[azslow3]

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.

[mgr]

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

[azslow3]

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.

[azslow3]

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.

[mgr]

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.

[mgr]

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.

[azslow3]

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.

[mgr]

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

[azslow3]

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.

[mgr]

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.

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?

[azslow3]

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.