AZSlow

Well, I have claimed it is possible but I have not claimed that is easy

So attached example need an explanation. You should be able to test it without device (since I don't have X-Touch), show display (in the Options tab) to see what values are considered.
Last MIDI event should display the last SysEx sent. Try to change track colors, add/remove tracks, move WAI, etc.
To try with X-Touch, in Feedback/SendColors scroll to the very last Action and uncheck "loop" option.

As first, I list what we need to achieve good result. Note that is not AZ Controller specific, but that explains why the procedure is relatively complicated in any software:

• We need to get the information about current color for each display. We should correctly process the case the color is not known (f.e. there is no track). We have to periodically check it is not changed. We don't want send continuously, so we should send changes only. We don't want send on any single change, we should collect these changes to send in one SysEx.
• Once there is at least one change, we should send SysEx

So now I describe how I have implemented that in attached example:
* Current color for each display (1..8 ) is saved into _ColorMap(_Ch) array of Software Sets. It is _Ch (1..8 ) dependent, AZ Controller works with index corresponding to current _Ch state. Note that name itself "_ColorMap(_Ch)" has no technical meaning, it can be renamed to "SomethingElse". But Action lists will be harder to understand.
* There are 8 "MonitorColorTrk X" controls. We need 8 monitors, and while putting all of them into one control is possible, it will be hard to work with. I have really created just one, "MonitorColorTrk 1", and than "Dup" it (once finished and checked) another 7 times, changing "Set Ch to 2...8" only.
* "MonitorColorTrk X" is organized such way it is just "_Ch" dependent. So first I set "Ch", then call common color evaluating function "fChooseColor(_Ch)" and then specify Monitor to track changes in the color.
* fChooseColor(_Ch) select _Ch WAI track volume and then map selected track color to _ColorMap(_Ch). Note that happens during "monitor changes evaluation" phase, all states are "local copies" of corresponding global states. So changing _ColorMap(_Ch) there does not immediately change global value (called "engine value" in AZ Controller). Also note I first reset the State to the first. If there is no strip, mapping will not happened and that initialization takes case about reasonable result in such case. Finally, I set "current Text" to the value of selected State.
* back to "MonitorColorTrk X"... Monitor there track "current Text" and compare it with last value when the monitor was triggered. So, it will be triggered initially (on preset loading) and if we evaluate different color (and so the text is changed). Note "ultra" speed (every Surface Cycle, normally 75ms) and "Priority 1". Priority should just be lower number (higher priority) relative to sending Monitor I explain later.
* in the Feedback for Monitor I set global value to current local value (by now, we know it is changed...). And I arm sending Monitor. If more Monitors trigger in the same cycle (f.e. you move WAI), they will all re-arm the same send monitor, so it will be triggered only once.
* SendColors control just has one monitor. It has type "Timer", but parameter "Once". That means it can be triggered by "Reset Monitor", but it is never triggered by itself. Note its priority, we want it triggers after other 8 Monitors have checked for changes. We could trigger it "next cycle" instead of "now", then priority is not important. But that will introduce small extra delay.
* in the Feedback section of SendColors I compose SysEx from current colors. Note that "Text from State" and "Display" actions there are for debugging, they don't influence what is sent. So effective list of Actions is not so long, just "_Ch = n" and "Append SysEx" for n = 1 to 8.

 

I hope you manage to understand how that is working. But if you give me more details (controller, what should change the color, etc.), I can create an example.

It all depends what you try to achieve when generating SysEx dynamically. Appending states by position is useful when there is corresponding set used for something else. F.e. you have a set "Ch" (1,2,...) and you need construct SysEx which includes corresponding position (0,1,...). Appending values of states is useful when there are unusual values linked to position, f.e. "Color" 1,2,3 needs values "17", "ac", "5e". In most other cases, just adding fixed byte(s) based on Action Conditions is simpler and easier to read.

That is supported. AZ Controller has no conventional variables, but it has "Software State Sets". Current state of a set can be appended to SysEx, by position (f.e. the 3d state state will append byte "02" to SysEx, since states are counted from zero) or the state label (should be hex, f.e. "a8").

I have just checked in 2 different browsers, and the link in the Installation instructions was working as expected...