there are something, which must be very complicated realised:
to set a channel number to a SelTrack software state, it must be realised like this:
'_Ch:1''Mode:Track'-SelTrack->1 *
'_Ch:2''Mode:Track'-SelTrack->2 *
'_Ch:3''Mode:Track'-SelTrack->3 *
'_Ch:4''Mode:Track'-SelTrack->4 *
'_Ch:5''Mode:Track'-SelTrack->5 *
'_Ch:6''Mode:Track'-SelTrack->6 *
'_Ch:7''Mode:Track'-SelTrack->7 *
'_Ch:8''Mode:Track'-SelTrack->8 *
but if software states could also be used to assign, this all could replaced with:
'Mode:Track'-SelTrack-><_Ch> *
I think about this for long time... But every time I need that, I ended using different solution. See my next comments:
Action conditions should be also available to compare software states
Track->5
_Ch->5
to compare same Track and _Ch must be realised like this:
'Track:1''_Ch:1'...*
'Track:2''_Ch:2'...*
'Track:3''_Ch:3'...*
'Track:4''_Ch:4'...*
'Track:5''_Ch:5'...*
'Track:6''_Ch:6'...*
'Track:7''_Ch:7'...*
'Track:8''_Ch:8'...*
but if also software states could be used to compare, this all could be replaced with:
'Track:<_Ch>'...*
The "ground" rule of AZ Controller language was the simplicity of conditions: "exactly this or any". Logically "if something".
There was many wishing to "extend" that, with "if NOT something", "if a > b", "if a = b", etc. But till now I "resist"... Not only that complicates the basic "language" (I know, with introduction of Monitors it is no longer simple), that will directly affect the interpreter performance. Thanks to rather simple check for conditions ( cond->state == cond->state->set->current_state), the interpreter can handle huge number of long monitors, since at any particular time only a fraction of Actions should be executed.
Let me explain how I usually handle cases like your example with selection.
I use "Set State dependent Set", in programming language 2 dimensional arrays. I mean:
_Ch: 1 2 3 ...
Selected(_Ch): No Yes
"Selected(_Ch)" (where (_Ch) part is just a text) should be marked as dependent from _Ch.
Than things are no longer boring:
* in "Selected" Monitoring, since _Ch is already set, 'Set State Selected(_Ch) = Value/No/Yes (engine)' set it
* can be used later as "Selected(_Ch):yes"
But I rarely use that, only for very specific purpose. When something depends from "selected" strip, I explicitly use "Select Track <current>". When desired "Save/Recall" and "Mark" Actions.
If you can explain what exactly you try to achieve, may be I can recommend some way to do that (or understand that something is not possible without "Set" = "Set" operation
)
to assign ACT controller values for Rotary, Slider or Switch:
...
but if software states would be usable this could be also replaced:
Mode:ACT'-ACT S<_Ch>+(Bank)x8*
this will be most important if there are lists to compare with much more elements
Completely agree. I simply forgot that Action when parameterizing other actions. Probably I will add that soon.
PS. After our last conversation, I have decided that I want compare presets... and I have remembered that is close to impossible (MarKo has written a nice utility, but it is not precise). So I have started to implement the text preset export feature. A kind of "decompiler" of internal byte code. Still in progress, but more then a half is already done
There will be no "compiler" in foreseeable future, may be not at all. I mean it will be impossible to convert text preset into normal one, but it will be possible to compare text representations of two presets and see all differences, including all parameters. Helpful in case some preset was changed "in parallel".
