AZSlow

I suggest to use Mackie plug-in in HUI mode and try to create preset for MIDI mode to use more channels.

Each device is a bit different... While Mackie HUI/MCU is a kind of "standard", in practice only devices with exactly the same controls can be used without limitation with related software. Avid and other have tried to create "universal" protocols, also with questionable results. Dedicated software/preset for concrete device is always the best solution to get everything possible from it. Universal solutions are always "compromises".

Thanks for the responces.
There maybe hope yet for this mixer.
This what I have found out so far:
The following are being observed from the last midi message in the AZ control
Ramsa set to HUI DAW  control. Faders 1-8
Fader 1:Ch1 CC14: 0, Value 0, to 16352.
Fader 8:ch1 CC14: 7, Value 0, to 16352
MASTER FADER sends sysex message:
Sysex<54>12 45 20 [53 51 20 78 40 40 3 30 41] (fader down)
Sysex<54>12 45 20 [53 51 20 78 4c 7e 3 33 42] (fader up)
Faders 9 to 16 do not send anything in this mode.
Faders 1-8 do respond from Sonar and I can change banks in sets of 8.
The master fader currently does not move in either way.

There is this blog about DA7

http://www.cambriarick.com/DA7/midi.html


It is mentioning MIDI can be assigned to faders etc.,
and it can be configured, whether the fader just sends MIDI, or controlls volume at the mixer.
You need to use the Custom/MIDI fader layer on the DA7.
So I guess it is at least 16 faders you can use for MIDI control.
Whether the faders also receive MIDI and react to that is not being mentioned.

DA7 also seems to support MMC for transport command like Play, Stop, Fast forward and Rewind.
So you should be able to use that as well, letting AZ Controller emulate an MMC recording device,
which it can do perfectly.

I am currently working on a preset for a very similar project for my Tascam DM24 console,
so maybe one could make that preset usable for both DA7 and DM24, provided we can force DA7
to send the same MIDI CC messages from faders and buttons as DM24 does, or two different but very similar presets.

See thread called "Math functions, variables, message construction" in the "Discussion" group.
It mainly deals with arming tracks for recording, which is supported by DM24 via MMC,
as this required new Bit Action functionality in AZ Controller that AZ kindly implemented.
I do not know whether DA7 supports track arming over MMC as well, but at least transport buttons should be exactly the same for both consoles I believe.

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.

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


 

Do you have a link to WR-DA7 documentation which mention HUI? I have only found the documentation for 2.0 update and it doesn't mention HUI (while it mention MIDI improvements).

It can happened the mixer works just with 8 channels when in HUI mode (all DMs I have checked so far limit "DAW controlling more" to 8 channels). MCU is specified as 8 channels per MIDI port (and WR-DA7 has just one), I thing the same is for HUI (there is no half way official docs for this protocol). It is easy to check - if in AZ Controller when you operate other channels you see some changes in the "Last MIDI event", these controls are sending something. Otherwise not.

For 8 channels HUI you can use standard Cakewalk Mackie Surface plug-in, it has HUI mode and it is more "stable" and complete then AZ Controller presets for MCU/HUI (I never had these devices).

-----

With AZ Controller you can try to use direct MIDI control. From the documentation faders and some buttons can send/receive MIDI. Again, you can use "Last MIDI event" to check something is received. And if you manage to get MIDI sent from all 20 channels, we can make a separate preset for that. Note that in this case normally mixer audio is synced to controls, I mean if you change level of the track that will change level of the mixer channel as well. When you used mixer for audio, that can be desired or not desired effect, depends how you want use your gear.

Hello.
I have a Ramsa WR-DA7 digital mixer.
Is it possible to control more than 8 channel faders at the same time?
The mixer uses HUI protocal.
I can connect the surface with the   AZ control. (HUI)
I can control 8 channels only at a time.
The mixer has 16 channels Plus 4 busses and a master.
It would be great to get all the faders controlling.
Only one set of midi in/outs.
My DAW is Sonar Platinum.
Any ideas?
Thanks...

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.

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?