My intention in no way was an attempt to stop your questions! You are welcome and I can write about the staff all the day long. I just do not want you get mad from my long posts in bad English
So, the execution order.
1. I have separate Monitors list with all monitors from all controls. So, every time Sonar call me (~13 times per second) I check either some monitor is "armed". For ultra, the arming is "1", Fast, Normal are "2", "6". "Once" and "State" monitors are not armed till requested explicitly, "State" monitor is armed when persistent state is changed (I have already explained that each State Set has "current" state which is system wide and persisting and "current monitoring" state, reset before any monitor execution to corresponding "current").
2. WAI Monitor::State monitor is executed once initially (armed during preset loading) and then stay unarmed till the state is changed.
3. WAI Monitor::Timer "Normal" is armed all the time, so every 6 cycles its arming counter drop to 0 and it is time to execute it.
4. The monitor execution procedure is the following:
4.a it takes the Logical Control (WAI Monitor) and execute it in "dry run mode", which means
4.b "State Monitor" action does nothing in "dry run mode"
4.c "Call _funcWAI" is called in "dry run mode", so
4.d WAI Track -16 set "current monitoring parameter" to "WAI Track -16 volume". If current WAI track is less then 17, the result is "invalid" and so "Selection" set "current monitoring state" is set to "Invalid". Let say current WAI track is 9, so that is the case.
4.e Set "Where in WAI -> Track 17-24" is NOT executed since "Selection:Valid" Action Condition is not true.
4.f WAI Track -8 set "current monitoring parameter" to 9-8 = 1 (first track volume). That is Valid parameter, and so "Selection" is set to "Valid"
4.g "Where in WAI -> Track 9-16" is executed in "dry run" mode, that means "current monitoring" state for "Where in WAI" is set to "9-16". The action also has "Final" flag set, so the execution of funcWAI is terminated and returned to "WAI Monitor" list (from where it was called)
4.h "Timer" is reached, its Action Conditions is checked (it has no visible, but there is still one implicite Note On). We see that it should be executed. That is "Our" timer monitor, so "dry run" execution is terminated, with result that we should call the monitor.
4.i Feedback Action list of "WAI Monitor::Timer" is executed in "Monitor" mode (not logical, not "dry run", it is third!).
4.j "Where in WAI: 1-8" is not satisfied, so skipped.
4.k "Where in WAI: 9-16" is satisfied. So, thanks to "Set engine state" flag, both "current" and "current monitoring" states for "Where is WAI" are set to "9-16". If "current" state was already 9-16, nothing happens. But if it was 1-8, it checks either there are some "Where is WAI" Set State Monitors. We have one! "WAI Monitor::State Monitor" is State Monitor for "Where is WAI". So, it is armed (with "1"). The action is "Final", so that stop Timer monitor execution. Since that is Timer monitor, it is rearmed with usual delay, "6" cycles in case of "Normal" speed.
5. If you remember, we are still in all monitors/timer check procedure. If our Timer and State Monitor have the same "priority", the order in which we check them is undefined. But since Timer has priority "0" and State Monitor "1" we know State Monitor is not checked yet in this cycle. So, the system check it.
6. We have armed State Monitor in 4.k, so it should be executed.
7. The system start "WAI Monitor" Logical Control "dry run" (yes, again!)
8. There is no actions before "State Monitor" itself, so its conditions are checked (satisfied) and Feedback actions are executed.
9. "Where is WAI" "current monitoring" state (which is the same as "current", as set prior "dry run" execution) is put to Text buffer
10. The Text buffer is displayed.
11. There is no other actions, there in no more monitors, State Monitor is disarmed, all monitors check cycle is ended.
12. The system continue to work from (3).
If you put all that in "C", the procedure is not going to be significantly shorter. We have to get current WAI, check it against our predefined values (9,17), check what we have displayed last time and in case it is different display new value. The preset has 11 lines (actions) for that. Can you write that procedure in "C" or other "normal" programming language in less then 11 lines?
One more note. The location of the "State Monitor" in Logical Actions list is not important. We could put it into separate Logical Control. We could put it between "Call" and "Timer" or after "Timer" as well. But in that case, it its "dry run" the "Call" is executed again. In that particular example, it will not influence the result, but it will "waste" CPU cycles. That is why I always put "State monitors" as the first in the Logical Actions. Since it does "nothing" by itself (in all 3 modes!), it can not significantly slow down other "dry runs" (in this example, the Timer "dry run"). So I do not create separate Controls for that monitors which just "bloat" the number of controls in the list (there can be 100 or event more, one per real hardware message plus functions)