I attach preset which implements what I could find in the text.
Note: it is a mod of my original 0 preset, not your 7. I have asked you to not modify anything after assignments, except may be colors. Things got quite changed in 7 (I have warned that is easy). So I had to repeat all assignments in my preset following yours. Future versions will be mods of this (
preset.
Modes: Record (default) and Mix.
Mode switch: "Up" pressed for more then 1 second (Long press)
Mode Record:
Buttons: RTZ (no LED), STOP (LED, diff on Pause), PLAY(LED, diff on Pause), Exclusive record arm(LED for current track), REC(LED), File/Save (no LED), Set Loop times (no LED), Loop on/off (LED)
Knobs A: Jog measures, Jog beats (Ribbon mode, not really good for knobs since fixed to +-64 units)
Knobs B: Volume, Pan, Inp. gain for current track
Arrows: Undo, Redo, previous and next track
Mode Mix:
Buttons: Mute (LED)
Knobs A: Volume
Knobs B: Pan
Arrows: Undo, Redo, previous and next blocks
Block is auto-aligned to 8, so it can start from 1, 8, 17 only. Block is independent from current strip, switching to mix mode recall last WAI.
Preset should recall "Factory 1" on loading. LEDs should go off on project closing (may be on Cakewalk closing as well).
-------------------
Now answers on some of your question:
* There is MIDI with initial flag, as a separate Action type. "SysEx like" MIDI events was introduced to construct simple MIDI events "on the fly", the same way it was possible with SysEx. Complex construction is not possible on preset loading.
* Any value on Rude parameters toggle (ignoring the value). That is a bug (not sure where), probably overseen since never used. But there is better method to disarm everything, which I have used now.
* modes / long pressed / etc. have no dedicated Actions. They can be implemented using Action Conditions and Timers, as you can see in current preset (f.e. Long for "Up"). There are Tutorials which explain some of ideas behind. Sure, all that significantly complicates Action lists. Hardware producers are very proud about "2-16 configurable hardware presets", write many pages of documentation about the feature and give special utilities for setup. We do the same in software, that can't be done completely without effort.
In general, anything above Startup preset with AZ Controller is complicated. Especially any feedback to controllers. That is the reason why "deep controller integrations" (for any DAW and controller) is normally a job for dedicated professionals. Users normally just "assign MIDI".
While AZ Controller allows construction of "smart" presets without huge programming skills, it can't hide the complexity of the topic.
Just some examples:
- not everything in a DAW happens "instantly", f.e. after you set Mute it takes some time (till the next audio buffer processing) before the channel is really muted.
- not everything in a DAW is buffered. Which commands are buffered and which not is DAW and command dependent.
- good design of controller preset foresee "external" changes, f.e. current track, transport, WAI, etc. can be changed by mouse. Controller should not go "out of sync" in this case (some controllers in fact ignore that idea on hardware/firmware level, f.e. by switching transport LEDs on corresponding buttons operations only).
- something can be "not there", f.e. if your button control strip 8 mute it can happened there are less strips in the current project. Feedback should not be confused by that
- as a kind of consequence of all previous topics, it is rather bad idea to organize feedback as direct reaction on controller operations. The feedback should follow current real situation inside the DAW.