SysEx messages all mapping to ctrl 85

[Linzmeister]

We have already "disable all automation writes", we can add "enable all automation reads" there, in transport. Other approach is to add transport buttons into automation mode, for example on SEL buttons.
But depending what you do more, switch banks or play/pause, may be we should use RTN1-2 SOLO. Up to you (I have not defined these buttons yet).

I was thinking that the Touch/Follow Automation Off button would cover the overwriting automation with mouse/iPad/ other control idea you mentioned..  I may have misunderstood your line of thinking in this department.

That time I was hoping some buttons can me momentary... That is as I use that: press corresponding button as an indication the control is "touched", overwrite automation with control, release the button. For that to work, we need per fader button. F.e. we can sacrifice "automation read" for that. Other approach is to use Automation read and Overwrite automation mode. Instead of Automation read, we can use "global motor off"... Decisions, decision 

It turns out to be much simpler than that...   Turning off Automation Read per track, allows me to overwrite an individual track... that becomes the touch button(s).. already done... and it only matters when automation level is changing - solid line...  When the automation line is dotted, I don't even need to disable the read function.   

Works beautifully with touch and latch modes!!   Overwrite mode makes a mess of things, but hey, 2 outta 3 ain't bad..
See attached images. 
Track 1 Touch mode
Track 2 Overwrite mode
Track 3 Latch mode

All fought with my fingers with Read ON.  Turn Read OFF, and new automation was recorded in all modes.  Turn Read back On and it resumes nicely.

Adding "enable all automation reads" to transport mode does sound like a good idea - perhaps on CH 6 ON button.

Now you have me thinking that RTN 1&2 SEL buttons would be better for BANK -/+, because we don't need constant feedback on banks - and currently when I press the RTN 1&2 SEL buttons, Selected channel already snaps back to the focussed channel or the outside WAI indicator on the Master SEL. 

Could Prev Marker & Play/Pause be duplicated on RTN 1&2 SOLO buttons respectively... This means when setting markers, looping and punching I can use the prev marker & Play ON buttons in the Transport mode, and when mixing/writing automation, use prev marker & play by the RTN SOLOs for quicker access??

Some of the buttons are behaving as though they are momentary. 
Button LED off --> Press button --> action gets performed --> Button LED turns off automatically.
Home/RTZ,
Prev Marker, Ins Marker, Next Marker,
End,
Global Write Auto Off, 
Mark In, set loop to Selection, Set Punch to Selection, Mark Out
Undo, Redo,
Save and Save As
all buttons above behave momentary, which is good and appropriate I think.
ie All except 1 solo light starts at OFF and returns to OFF after pressing.  The only SOLO light that stays on after pressing is the Bus WAI button.

Stop, Play, REC, Auto Loop, Auto Punch, Scrub, Tracks, and Bus buttons behave in latch mode, which is also good and appropriate.

I have realised that we could save a button by putting TRACKS and BUSSES onto a single button.  ON is one mode, OFF is the other...  I have not yet revised the button assignments and have no idea what I would put in it's place.

It can be that you will be able to assign buttons yourself... Not more difficult than changing keyboard shortcuts in Sonar, at least for simple operations and without LED feedback.

Yup, I am trying to follow your configurations, and learn the language. 

Scrub is not something that I have used a lot in the past.

Scrub idea is simple: when this mode is on, in case you move "Now" time, using mouse or jog wheel, instead of jumping to new time Sonar start play to this time. Also reversed.
In practice, for most users (including myself) that feature stuck audio quick or does not work at all (with Softsynth). And without jogger... I do not know.

I had a go at setting the RTN 1 Volume to be a jog wheel..  I couldn't get the control to perform jog, but when I pressed play inside the controller, it moved the Now Time and with scrub on, it played the audio.. baby steps...
I don't use any midi instruments so Softhsynths fall nicely into the I Don't Care category.

I always find editing to be a slow and painful job - and that may be because it is precisely that. 

It might be useful to duplicate the scrub function onto the EDIT mode buttons.. and operate with jog/shutttle?  As mentioned a couple of days ago, the edit mode buttons need revising. 

I do not have any professional experience with editing/mixing, not even close.
....
Just to understand how all that works, I have learned what Mackie Control does and how other devices are used. I have never seen any console in real life... I have bought used StudioMix just to touch motor faders, to understand what all that about.

My profession is Control Systems, DBs, with experience in automatic/half automatic control and monitoring, including quick reaction situations and routine financial operations.

The Control Systems experience has served you very well indeed for this application!! 

Back to the preset. Have you checked that all LEDs are correct? Arm/Automation/Transport/Loop/etc?

Mute, Solo, Rec Arm, Inp Monitor, Automation read and write LEDS all match up perfectly.
Transport button LEDS as mentioned above behave in an appropriate manner per button.

The only undesirable side effect in Test 12 that I can see, would be that in Transport mode, pressing the SOLO buttons to perform Home, Marker jobs, End etc. also changes Focused/SELected channel because 01V is sending SEL message after every SOLO ON message. 

In all other modes it makes sense to select the channel we just soloed, input monitored, or Write enabled.  Would a Boolean variable _SoloPressed=Yes/No being set by SOLO message and being reset by SEL message and setting SEL back to focused Channel help here. 

Code Select Expand


Psuedo Code Logic
If Mode=Transport and MIDI IN is Solo message
      Do Home/marker/End/Set Loop to Selection etc
      SoloPressed = YES
endif

If Mode=Transport and MIDI IN is SEL message
      IF SoloPressed = YES then
            MIDI out SEL message to indicate current focus,
            SoloPressed = NO.
      Else
            change focus to SELected Channel
      endif
endif

crude but demonstrative.

And finally there will be some pause... I will proceed with Ch17-24 as ACT controls then.

When you're ready is fine.  I have enough already that I can actually finish a mix I have been working on for a while... having EQed and compressed with mouse and keyboard..

[Linzmeister]

well, well, well...

It turns out that after reading the MIDI spec found on the yahoo group much more closely, that the unsolicited message thought to be a ping, is actually a remote Meter request message..

So, I followed the Strip Level Monitoring tutorial and added it into a copy of your work and I was able to get *something* working first go... for a single track as long as MIDIOX has both an input and an output port open to the 01V.. 
If I close MIDIOX the metering stops working..
If I close either of the MIDI ports IN/OUT in MIDIOX it stops metering. 
Not entirely sure what is happening there - may just be MIDIOX feeding back to the 01V and maybe I haven't done anything significant at all.

Maybe it is the 01V sending metering data to AZcontroller...  because there is a lot of additional Last MIDI Event activity.
I thought I constructed the command to show the Current track level to the Master meters on the 01V, but I also saw Ch 13 Meters on the Home screen, which is where the sp/dif output from Sonar is going.. 

Normally there is nothing on the meters in Local Off mode, so something definitely changed, but not sure if I am sending metering to the 01V, or it is sending metering to AZController..

I am starting to look at the Clip Edit Tutorial.  trying to understand all the states and feedback you put in place in the 01V preset and looking at the editing preset to see what differences there are. - particularly with the mode feedback.

[azslow3]

I am at nice place... with nature and close to no internet  So I barely turn on my computer these days.
I think we will send some metering once I am back. I have not found messages we have used so far in yahoo files, so I have probably overseen something.

[Linzmeister]

Enjoy your holiday

[Linzmeister]

I have done a lot of reading of the user manual and the programming you have done in tutorials and the 01V preset.  I'm starting to get the hang of the layout.

Variables are Software States created in Options Tab,
Functions are created in Options Tab --> Hardware Controls  <New Control>  then attaching a new Logical Control to hardware control on the hardware TAB and then "program" is added in the Logic tab.

I still haven't found where you are sending the SYSEX out to the yamy though.  I thought it would in the feedback tab - SysEx/Midi begin, append and send... but it is not generating any output for me..  I'm probably using it wrong.

I think the yahoo group documentation is inaccurate..

While trying to do some more work on the metering by myself, I noticed that when I change fader modes, the PING Message changes and when I turn Local Control On, the last PING message has a 00 as the last byte.  This matches up with the fact that different screens require different metering.

I am currently adding system hardware controls for the various pages and multiple metering states.  I will upload the modified preset when I am done.

[azslow3]

Sorry, holidays happened to be more events intensive as I have thought 
So I have no time for time intensive and concentrated work (required for presets modifications to not break anything). Also I am preparing the code modification which should significantly simplify the configuration. But I am back home next week, and while there will be another time consuming task (flat change), probably I will find time for the preset.

SysEx sending is done from feedback. But since most messages are send "combined" from many strips, that is done not directly: corresponding monitor save required value into state, mark that value should be sent and trigger yet another monitor. All monitors have correct "priority" set, so all that happens in one go: parameters are checked for changes (for all strips) first, these changes are saves in states, if at least one parameter is changed, (single) generic sending (for one parameter type, f.e. for solo buttons and  faders it is different) is triggered.

Note that configuration actively using "call" (== function in conventional programming), so SysEx actions are defined in the "Logic" tab while called from Feedback.


(the following is most complicated for understanding part in AZ Controller concept, but that is what make it so flexible while keeping the configuration reasonably small).
The same Action does different things when executed in different contexts: directly in logic (when MIDI message is processed), during monitoring (to determine either the parameter is changed) and during feedback execution. The concept is used in small subset of conventional programming languages, but it is rather handy in event driven situations (Control Surface logic is event driven, where MIDI messages, parameter changes, transport state, etc. are events which require some attention).
That is better explain by example. Let say we want attach "Mute" button to current track "Mute" parameter in Sonar, with feedback. For "simple" surface (Y01 in local off was not thought to be used that way, so in our preset that is more complicated, but the concept is the same):
For MIDI message from the buttons (let say "CC 10"), the following Logic sequence is defined:
(a) Select "Mute" parameter from "current" track
(b) Toggle selected parameter (1->0 and 0->1)
(c) Monitor parameter value
And in the (c) Monitor, we send current value back (CC 10 Value 0 if not muted, CC 10 Value 127 when muted).

1) When we press the button, (a) and (b) should should, to toggle mute. But (c) should be "ignored" (it is to get value FROM Sonar, not change it).
2) When we check either we should call Monitor, we want only (a) is executed, but not (b) (we do not want toggle all mutes 13 times per second all the time...).
3) If we detect parameter change, we call Monitor. That context is different from (2), it is more like (1). But for good reasons some Actions are working not exactly as in (1).

"Conventional" way is to define 3 separate "Action lists": one for MIDI reaction, another to detect parameter change and third to do something on such change. That is how it will be written f.e. in C++ (CW SDK), JaveScript (some other DAWs...). In each list, the first thing to do is select required parameter. So, the reaction and parameter change detection will be different just in final logic: either change the parameter or check it is changed in Sonar. In AZ Controller that is done inside one definition. Easier to define and keep in sync (physically Sonar parameter, button signal and in case of Y01 internal mixer parameter value are independent "numbers"), but harder to understand initially. Do you remember initial "tests" with faders logic? The difference in configuration was 2-3 actions, and so easy to modify (at least for me), while the difference in what happens behind the scene was big. If I try to do the same in C++, preparation of such "tests" will take ages.

I hope the explanation can help you imagine the spirit of AZ Ctrl   

[Linzmeister]

CH   SysEx out
1   23 01 00 10 00
.....
15/16   23 01 0D 10 00

OK, While I have been looking at Fader modes and LCD screen menu MIDI data I have uncovered a better understanding of the 23 01 xx yy zz commands..

And another misprint in the yahoo group document

STATUS      1111 0000   F0   System Exclusive Message
ID No.      0100 0011   43   Manufacturer's ID No.(YAMAHA)
SUB STATUS.  0001 nnnn   1n   parameter change n=0-15(Device Channel No.1-16)
GROUP ID      0011 1110   3e   MODEL ID
MODEL ID      0000 0100   4   Device code (01V)
PARAM TYPE   0100 0011   3   controller (type) sent as 23 even though the HEX says 43 and the decimal says 3
DATA         0000 0001   01   control No.(LCD-Fader mode)
            0ddd dddd   dd   channel select(0-30)  This bit we already guessed
            0ddd dddd   dd   LCD select No.(0-17) Fader Mode/Screen
            0ddd dddd   dd   PAGE No.(0-4)
EOX          1111 0111      F7   End Of Exclusive
         
xx = channel select(0-30)      1-31      CH
yy = LCD select No.(0-17)      1-18     Fader Mode / Screen type..
                                                          Home/EQ/Dymanics/Send1-4/FX1-2/Option I/O
                                                           /Remote/Pan&Routing/View
zz = PAGE No.(0-4)            1-5    Page

Detailed data samples to follow.

[azslow3]

I am back home. And I am finalizing new changes in the AZ Controller.
I will rework Y01 preset then (it will be smaller...), fix spotted select issue (with transport buttons), etc. If you want me start from your current preset (you write you have made some changes), please upload it. There is no "merging" functionality for presets (I miss it... but it is a huge work to make it).

[Linzmeister]

I hope you enjoyed you break.

Please find attached the preset with my attempt to add metering.  I have added midi mapping for a lot of other controls..EQ, Dynamics, Aux Sends and all the newly discovered meter Requests which I have abbreviated to MR XX, xx being the hex value of the message (highlighted green in the attached image)

Because of the conversation about the meter monitor feedback calling an action from the logic tab which I have not got my head around yet I deleted the feedback which I created just to cleanup a little.

I started this over about 3 times from the test 12 preset because I clicked on the wrong thing and changed a setting I could not remember the original value of..  There are several detached logic controls.  I was able to delete many of them, but the ones that remain I could not figure out how to delete - I assume there are references to them somewhere, but I can not see where they are..  I duplicated too many hardware controls by accident and tried to clean up but failed.

I have set all the MR XX and Select buttons (23 01 xx yy zz) to system controls in order to prevent them them from annoying me while I was mapping the rest of the hardware controls..

I have created Software States for the various fader modes and LCD pages which can now be extracted from the 23 01 xx yy zz messages (in table in attached image).  I have made  the _FaderMode dependent on the _LCDpage... but that may be incorrect logic.

I will use some of the fader modes and pages as modifiers for the PAN control to give me a HPF and LPF and an additional 8 ACT rotary controls.. but that is for a later date.

All the feedback seems to have stopped working.  Not only in this preset 13, but also in the unedited test preset 12 which I downloaded a second time to make sure I wasn't working off a dirty copy on the hard drive.   I hope I have not done too much damage.

[azslow3]

Agrrr.... We have "version clash" now, I have just finished my own v13 and during publishing noticed your upload. Not sure what to do, but I would prefer you test my version first. And once we make it working, I will try to put your changes into it.

Everything can go wrong: we have clash, both version have number "13" (some people think that number is bad) and there was significant changes in AZ Controller, you will need v0.5r3b340 (just uploaded test version) or later.

But I think we will sort that (also there is preset comparison tool from MarKo, which I can try to use to spot your changes).

So, my v13 should be the same as v12 with the following changes:

Adding "enable all automation reads" to transport mode does sound like a good idea - perhaps on CH 6 ON button.

There.

Now you have me thinking that RTN 1&2 SEL buttons would be better for BANK -/+, because we don't need constant feedback on banks - and currently when I press the RTN 1&2 SEL buttons, Selected channel already snaps back to the focussed channel or the outside WAI indicator on the Master SEL. 

This.

Could Prev Marker & Play/Pause be duplicated on RTN 1&2 SOLO buttons respectively... This means when setting markers, looping and punching I can use the prev marker & Play ON buttons in the Transport mode, and when mixing/writing automation, use prev marker & play by the RTN SOLOs for quicker access??

And this. RTN2 SOLO LED should indicate Play/Not play in all modes.

Some of the buttons are behaving as though they are momentary. 

Y01 buttons are momentary, the preset tries to make them work as such.

The only undesirable side effect in Test 12 that I can see, would be that in Transport mode, pressing the SOLO buttons to perform Home, Marker jobs, End etc. also changes Focused/SELected channel because 01V is sending SEL message after every SOLO ON message. 

That should work correctly now.

Please check that feedback for everything is still as expected.

If you get no feedback at all, most probably Y01 is in different mode from "standard" (I mean the mode for which we have created the preset). May be some feedback settings are disabled. Also check MIDI settings.

[Linzmeister]

Please check that feedback for everything is still as expected.
If you get no feedback at all, most probably Y01 is in different mode from "standard" (I mean the mode for which we have created the preset). May be some feedback settings are disabled. Also check MIDI settings.

OK, the loss of feedback appears to be a CW thing.  After loading the new controller version and resetting the config and killing sonar a couple of times and deleting all the controller presets it still remembered preset settings, so I deleted the controller and killed sonar and re-loaded and imported the preset and it all cleared up. Full feedback restored.

Adding "enable all automation reads" to transport mode does sound like a good idea - perhaps on CH 6 ON button.

There.

The global Auto. Read & Write buttons don't appear to do anything visible in the sonar mixer - the tracks do not enter read/write mode when pressing the global auto. buttons in transport mode.

The Sonar mixer updates the read and write from Auto. Mode individual channel Auto. read/write commands,  but 01V status is always off.
Mouse clicking Auto. Read or Write in Sonar mixer does not update the 01V channel SOLO/ON buttons ..  just a feedback thing..

Now you have me thinking that RTN 1&2 SEL buttons would be better for BANK -/+, because we don't need constant feedback on banks - and currently when I press the RTN 1&2 SEL buttons, Selected channel already snaps back to the focussed channel or the outside WAI indicator on the Master SEL. 

This.

works a treat.  added 40+  tracks and banked up and down with the RTN Select buttons and 01V faders followed beautifully.. 

Could Prev Marker & Play/Pause be duplicated on RTN 1&2 SOLO buttons respectively... This means when setting markers, looping and punching I can use the prev marker & Play ON buttons in the Transport mode, and when mixing/writing automation, use prev marker & play by the RTN SOLOs for quicker access??

And this. RTN2 SOLO LED should indicate Play/Not play in all modes.

Another resounding success!!   prev marker and play/pause and play indicator all work fine.
yup, that will save lots of button presses and speed up the mix process heaps. 

The only undesirable side effect in Test 12 that I can see, would be that in Transport mode, pressing the SOLO buttons to perform Home, Marker jobs, End etc. also changes Focused/SELected channel because 01V is sending SEL message after every SOLO ON message. 

That should work correctly now.

Spot on!!.  Navigating the timeline and all the other Transport solo functions no longer selects the channel. pressing select by itself does select the channel, so perfect all round.

I would call that very positive progress

[Linzmeister]

Still trying to get my head around this:

The same Action does different things when executed in different contexts: directly in logic (when MIDI message is processed), during monitoring (to determine either the parameter is changed) and during feedback execution. The concept is used in small subset of conventional programming languages, but it is rather handy in event driven situations (Control Surface logic is event driven, where MIDI messages, parameter changes, transport state, etc. are events which require some attention).
That is better explain by example. Let say we want attach "Mute" button to current track "Mute" parameter in Sonar, with feedback. For "simple" surface (Y01 in local off was not thought to be used that way, so in our preset that is more complicated, but the concept is the same):

I understand sequential programming. GW basic/Qbasic
I understand event driven object oriented programming (VB6/VBA)
I understand inheritance and overriding functions. Java for Android SDK and some C/C++

Is AZC using any of these methods or a different principle again..
Does setting the priority control what happens each time the same action list is called?

[azslow3]

Please check that feedback for everything is still as expected.
If you get no feedback at all, most probably Y01 is in different mode from "standard" (I mean the mode for which we have created the preset). May be some feedback settings are disabled. Also check MIDI settings.

OK, the loss of feedback appears to be a CW thing.  After loading the new controller version and resetting the config and killing sonar a couple of times and deleting all the controller presets it still remembered preset settings, so I deleted the controller and killed sonar and re-loaded and imported the preset and it all cleared up. Full feedback restored.

There was several reports that some surfaces (with feedback) are stop working and the only solution was physically removing all related (directly and indirectly) Sonar configuration files so it regenerates them. But since you just had that, it is the first time I start to think that is real.

If that happens again, please save all "*.ini" files in %APPDATA%/Cakewalk/SonarXXX folder before restoring. It will be nice to give CW an example of such corruption.

The global Auto. Read & Write buttons don't appear to do anything visible in the sonar mixer - the tracks do not enter read/write mode when pressing the global auto. buttons in transport mode.

Write should work. It should DISABLE automation write if for something it was enabled. So it has no effect if nothing is enabled.

Read had to work. But corresponding Sonar command does not work, even when mapped to keyboard shortcut. I have found "Ctrl+F12" in X3 documentation and I have replaced the action. Does not work in X2 and I can not test in Plat. now.

The Sonar mixer updates the read and write from Auto. Mode individual channel Auto. read/write commands,  but 01V status is always off.
Mouse clicking Auto. Read or Write in Sonar mixer does not update the 01V channel SOLO/ON buttons ..  just a feedback thing..

There was a bug in my configuration, please check again.

I would call that very positive progress

Since Automation read/write feedback was the major change and because of one "typo" that new logic was not engaged at all, we do not know yet 

I understand sequential programming. GW basic/Qbasic
I understand event driven object oriented programming (VB6/VBA)
I understand inheritance and overriding functions. Java for Android SDK and some C/C++

Is AZC using any of these methods or a different principle again..

The concept is event driven. But monitoring heavily use yet another concept. I know it from Forth language, not sure it was used before it but I have not see wide use in other languages.

Override defines several different functions with the same name but with different parameters. Override redefine the function (a kind of permanently for particular object). Single function in Forth (btw. there everything is a function, even variables. It is "puristic functional" language) and Actions in AZ Controller (can) do different things in different contexts. In Forth, that is used so you can define compiler functions inside your program, f.e. you can in the beginning of your source code write a Basic interpreter and the rest of the program write in Basic (is it not fascinating?  ). In AZ Controller, that is the way to reuse the same list of Actions either to do something (f.e. set mute) and to monitor the same thing in Sonar (to send feedback when mute is changed by mouse). As with Forth, that can enormously reduce the size of the "code" but since that is not used in "usual" languages, the concept is hard to understand.

Practically, the implementation is simple. Imagine that any Action is an Object with 3 methods: ExecuteInLogic, ExecuteDuringMonitoring and ExexcuteInMonitor. F.e. "Set Value" set the value in the first method only, other 2 methods are "empty", "Monitor" Action has the code in the second method only, "Select ACT parameter" has first two defined, "Set State" has all 3 defined (but a bit different way), etc.

Does setting the priority control what happens each time the same action list is called?

Priority specify in which order monitors should be executed within one monitoring cycle (every 75ms with standard Sonar settings). In Y01 preset case that is quite important. F.e. when strip volume change is spotted, it is not send immediately. It is "waiting" for other strip monitors and trigger "Feedback" monitor. We want "collect" all volume changes before we send any to Y01 (probably you remember aggregate SysEx discussion) so we want that sending happens in the same cycle but after all channel monitors. Even more, it can happened that the mode is changed, and so monitors should start monitor something else... Maintaining the order in the Feedback Tab is rather boring, so I have introduced "Priority". State monitors usually have 0-1 (depending either state change can trigger another state change), channel monitors have priority 3 and sending monitors priority 4.

All together that sounds as an overkill: why not just check state changes, loop over parameters, collect changes and send them in conventional sequential code? In practice, CW MackieControl plug-in has >2500 C++ lines. Mack.Control preset for AZ Ctrl (which has the same functionality, it was created to mimic original C++ code), even outdated (can be significantly reduced using new AZ Ctrl features), is simpler.

As observable example, you can compare Bitwig code for NI S keyboards (written in JavaScript) with MackieTransport preset for AZ Controller. I am sure someone will find JS code simpler to understand. But as soon as things go more complicated, (non interactive) script writing become "real programmer" job. I do not claim everyone can create Y01 preset, even in its current version, but not many people have managed to write it in C++ either . And for me, configuring AZ Controller is much simpler then writing new plug-in in C++ for every device

Well, my priority now is to paint walls in 3+ rooms and move there... So probably this weekend there will be no new versions.

[Linzmeister]

The global Auto. Read & Write buttons don't appear to do anything visible in the sonar mixer - the tracks do not enter read/write mode when pressing the global auto. buttons in transport mode.

Write should work. It should DISABLE automation write if for something it was enabled. So it has no effect if nothing is enabled.

Read had to work. But corresponding Sonar command does not work, even when mapped to keyboard shortcut. I have found "Ctrl+F12" in X3 documentation and I have replaced the action. Does not work in X2 and I can not test in Plat. now.

OK...  I am running X2, so it looks like that won't be happening for me.. others may be ok...

The Sonar mixer updates the read and write from Auto. Mode individual channel Auto. read/write commands,  but 01V status is always off.
Mouse clicking Auto. Read or Write in Sonar mixer does not update the 01V channel SOLO/ON buttons ..  just a feedback thing..

There was a bug in my configuration, please check again.

Individual track Read/Write  buttons work better now.  Still a minor problem with feedback for On/Solo LEDs.. When I switch from Default or Auto. mode to Transport mode the On/Solo buttons don't refresh to show the transport status.  Switching from Edit mode to Transport mode does update the transport LED status.  When I first started typing this, switching from Default to Auto. mode didn't update...  still some corruption remaining??

I also noticed that pressing RTN 1&2 SOLO to play also changed bank -/+ .
I see you added IgnoreSelect software state - which fixed the transport mode Solo button/SEL messages.  The condition in both cases is Transport mode as originally identified by me... a little short sighted I now realize.. as RTN 1&2 Solo operate in all modes and Select indicates focused track.

I tried editing  (SysEx:<43>.... Solo Btns 1-8) and also in 9-RTN2:...
       I copy and pasted 3 times the 'Mode:Transport'  - IgnoreSelect -> Yes
       I changed the Mode= Arm, edit and Auto respectively which corrected the behavour of channels 1-15/16 in all modes, but not the RTN1&2 Solo buttons..  (Woo Hoo, I did something that worked... partially  )
In the overview, I can see IgnoreSelect changing Yes/No when I press RTN 1&2, but it is still switching banks when I Play/Prev Marker via RTN Solo Buttons.
Wrong sequence of events??  Rtn Select SysEx being processed before ignore select??

((None)) _SoloRtnX:  IgnoreSelect -> Yes ...any mode

MIDI IN:
61 00 10 0F     
61 00 0A 0D
23 01 0F 10 00
23 01 16 10 00

The concept is event driven. But monitoring heavily use yet another concept. I know it from Forth language, not sure it was used before it but I have not see wide use in other languages.
....
Practically, the implementation is simple. Imagine that any Action is an Object with 3 methods: ExecuteInLogic, ExecuteDuringMonitoring and ExexcuteInMonitor. F.e. "Set Value" set the value in the first method only, other 2 methods are "empty", "Monitor" Action has the code in the second method only, "Select ACT parameter" has first two defined, "Set State" has all 3 defined (but a bit different way), etc.

aahh.. my head hurts..    So, I did some research on Forth.. and found some discussion about Context Oriented Programming.. in relation to a different language.. is this the principle in use here?
http://www.jot.fm/issues/issue_2008_03/article4/... 

Figure 3 starts to look a little bit like what you are saying.. yes??
So what is the UI mechanism (drop down box, Tab.. thing I have to click on) that you are using to decide which commands from the action list  are executed in each context???
.. I can't see it..  yet

Do you have other flags or code, not visible on the UI for determining the context, which are permanently associated with ExecuteInLogc, ExecuteDuringMonitoring and ExexcuteInMonitor?

What is the difference between ExecuteDuringMonitoring and ExexcuteInMonitor... timing?? 
"during" and "in" are very similar words.
"monitoring" and "monitor" are also very similar words

I do not claim everyone can create Y01 preset, even in its current version, but not many people have managed to write it in C++ either . And for me, configuring AZ Controller is much simpler then writing new plug-in in C++ for every device

Well, my priority now is to paint walls in 3+ rooms and move there... So probably this weekend there will be no new versions.

I had a busy weekend also so didn't get to spend as much time at this as I would have liked..  I hope you got the painting done and things moved in.  I hate moving house.. making sure that glassware and picture frames are packed so they don't break.. ugh.

[azslow3]

Individual track Read/Write  buttons work better now.  Still a minor problem with feedback for On/Solo LEDs.. When I switch from Default or Auto. mode to Transport mode the On/Solo buttons don't refresh to show the transport status.  Switching from Edit mode to Transport mode does update the transport LED status.  When I first started typing this, switching from Default to Auto. mode didn't update...  still some corruption remaining??

Logical bug in the new code (more precise, I forgot to add one check which has to re-trigger monitor in such situation). Note that Default->Auto is warring, I could not reproduce the bug with that combination and so there is no fix for that. Please check one more time either Default<->Auto can leave indication inconsistent. Please install b341.

I also noticed that pressing RTN 1&2 SOLO to play also changed bank -/+ .
I see you added IgnoreSelect software state - which fixed the transport mode Solo button/SEL messages.  The condition in both cases is Transport mode as originally identified by me... a little short sighted I now realize.. as RTN 1&2 Solo operate in all modes and Select indicates focused track.

Missing statements in configuration, should be fixed in v15

I tried editing  (SysEx:<43>.... Solo Btns 1-8) and also in 9-RTN2:...
       I copy and pasted 3 times the 'Mode:Transport'  - IgnoreSelect -> Yes
       I changed the Mode= Arm, edit and Auto respectively which corrected the behavour of channels 1-15/16 in all modes, but not the RTN1&2 Solo buttons..  (Woo Hoo, I did something that worked... partially  )
In the overview, I can see IgnoreSelect changing Yes/No when I press RTN 1&2, but it is still switching banks when I Play/Prev Marker via RTN Solo Buttons.

You understand it right.

aahh.. my head hurts..    So, I did some research on Forth.. and found some discussion about Context Oriented Programming.. in relation to a different language.. is this the principle in use here?
http://www.jot.fm/issues/issue_2008_03/article4/... 

A kind of. But much less "theoretical".

So what is the UI mechanism (drop down box, Tab.. thing I have to click on) that you are using to decide which commands from the action list  are executed in each context???
.. I can't see it..  yet

Do you have other flags or code, not visible on the UI for determining the context, which are permanently associated with ExecuteInLogc, ExecuteDuringMonitoring and ExexcuteInMonitor?

What is the difference between ExecuteDuringMonitoring and ExexcuteInMonitor... timing?? 
"during" and "in" are very similar words.
"monitoring" and "monitor" are also very similar words

Contextes are fixes: if an Action is executed as response to MIDI input, it is "ExecuteInLogic". "During monitoring" mean the list of actions which is in Logic list BEFORE the Monitor Action, which is executed every time the Monitor is checked, so with "Speed" intervals (for Timer and State Monitors, prior action in the Logic list are also executed in this context). "In monitoring" means that monitoring conditions are satisfied (f.e. the value is changed in Sonar) and it is time to execute the Monitor. The action list from the Feedback Tab is always executed "InMonitoring", but in case one of this actions is "Call", corresponding list ("function") from Logic list is also executed in this context.

I hope you got the painting done and things moved in.  I hate moving house.. making sure that glassware and picture frames are packed so they don't break.. ugh.

One good friend and colleague of me was willing to help with the transfer. But he has not waked up yesterday. I mean he will never wake up... He had no problems with health, he was never smoking or drinking, he was biking every day at least 2 hours (but with all measurements to not overdo), he was under 50 years old...  He has left his wife with 3 young children, I can not imagine her emotions and thoughts.
Sorry for off topic.