AZSlow

Now that the underlying logic is clicking, I'm focusing a bit more (than I should?) on the finer details.  Here's the current logic setup and accompanying problem:

I have changed my configuration to shift through tracks, busses, and the mains in groups of 8.  All of the switching back and forth is working just fine.  I added "function:select strip" when I change through each bank so that the WAI moves AND the first track in the WAI becomes selected, so I can immediately see it within the track or console view.  For example, when I have a project with 16 tracks, if I move from group 1 (tracks 1-8) to group 2 (tracks 9-16) the selected track successfully changes from track 1 to track 9, making it immediately visible in my console view.  This particular setup works great until I have a project where the total number of tracks (or busses) is not divisible by 8, which triggers the invalid selection conditional action.  This, too, works great for the WAI itself, but it does not select the desired track within WAI.  If WAI was set to tracks 7-14 and I try to decrement the group (select tracks 1-8), the WAI successfully moves down to tracks 1-8, but track 7 remains the actual selected track.  This leaves my console and/or track view improperly oriented.  The problem also arises if I trigger the invalid selection action as I try to increment the group, moving the WAI properly but leaving the selected somewhere in the middle of it.

Is this particular case I know the logic I want to implement, but I have no idea the way AZC wants me to approach the problem.  Thanks again for your help, Alexey!

I was making this much harder than it had to be.  Adding an unconditional "function:select strip" at the end of the logic for the group +8 and group -8 buttons selects the first track in WAI as I had hoped, no qualms at all.  I guess when you expect something to be difficult, it becomes easy to miss the simple solution.

I should clarify though that there still seems to be no way to select tracks within the busses or mains section.  This implementation only works in tracks.  The "select strip" function itself seems to have no affect on busses or mains, whatsoever.

SONAR CS API (Control Surface Application Programming Interface) has the call to get/set "current" strip. It does focus the strip in case the strip type has the focus but it does not change the focus to another pane.

I have found one workaround to do that. You can use "Move focus to the bus/track pane" Command to move the focus manually. You can generate "Shift+Up/Down" keystroke to do the same. It does not always works for me (sonar bug?).

From the source code from other plug-ins I understand that back in time there was no "current Bus". But it exists now. Unfortunately, there is still no "current Main", no way to focus mains as well (no such command). I can not even manually move WAI for mains (in console view), but it works throw API.

Sorry, I can not fix SONAR logical and usual bugs and "AZ Controller Community" is too small at the moment to ask CW for fixes. No one else is using CS API, so we can not cooperate with other projects. I try to do my best, but I am limited by SONAR itself.

I hear you, AZ.  I have been using Cakewalk for about 17 years now, and ever since I've been using WAI within Sonar it has been buggy.  I have the same issues you describe, usually where the underlying logic of AZC is implemented, and the track set legitimately changes, but the WAI indicator itself doesn't move at all (gets stuck).  Cakewalk definitely needs to address this issue since it makes their DAW feel like it's been properly forgotten.

As far as mains go, it really isn't so much an issue there since I doubt I'll ever have more than two channels to worry about and rarely find a need to control them.  That said, I really appreciate the "bus fix" you have described and look forward to implementing it.

Please, whatever you do, realize that I cannot thank you enough for your hard work on this project.  This is one of the most incredible programs I've ever had the pleasure of using.  I'm completely obsessed with it, and I'm amazed  by the avenues for "freedom" you have provided Sonar users.  I hope I'm not bugging you with too many minor glitches that don't deserve your time.  You've already moved mountains, and I don't presume to ask you to move another.  On the contrary, if there is anything I can do to help get the word out about your amazing program, I'd love to help out!

Quote from: SonarHatesMe on March 18, 2015, 03:53:34 PM
Please, whatever you do, realize that I cannot thank you enough for your hard work on this project.  This is one of the most incredible programs I've ever had the pleasure of using.  I'm completely obsessed with it, and I'm amazed  by the avenues for "freedom" you have provided Sonar users.  I hope I'm not bugging you with too many minor glitches that don't deserve your time.  You've already moved mountains, and I don't presume to ask you to move another.  On the contrary, if there is anything I can do to help get the word out about your amazing program, I'd love to help out!

AZ Controller is a fun project. If someone likes it, the mission is accomplished.

So, please continue to ask questions, features and report observed bugs. That will keep the project moving. As you can see, I am not overwhelmed with comments. If I count right, there are 3.5 users of this program (including you and me). I think I have time to implement everything one of us wants (when somehow allowed by SONAR ;) )

In case we get more people, we can try to submit requests to CW for CS related fixed. 3.5 customers is a good reason to move for me, but not for CW. In case you have some ideas what can be done from my side in that direction, please let me know. I am finalizing MCU preset now (not so easy without MCU device). I also have a plan to make build-in generic preset, so newcomers do not start from empty one. Up to now, I am thinking about X channel strips with Slider, Encoder, Y Buttons (Mute, Solo), Bank/Strip type/ACT mode buttons and the Transport section. X and Y will be user definable (I mean on preset generation user can set for example 5 strips with 4 buttons each). Internal monitor will show controlled parameter names for the strip/act section. In total, that is a kind of Generic Control plus ACT MIDI mix (without limitation to work with tracks only in the first one and the limitation on the number of controls in the second one). With your experience, what else should be included into that "startup" preset? Full scale MCU can also work on any (!) device, but the definition is quite complex. I do not think someone will be able successfully mod it for personal needs.

Well, I can't think of anything that you haven't covered that should go in a starter preset.  However, I am kind of curious about the potential for a "Mute All Tracks" button in Sonar.  I have implemented a very hacky solution, but I'm very unhappy with it.  It appears that although Sonar has a dedicated "Mute All Tracks" button in the mix bank, it doesn't actually have a simple command that can be called to replicate the action.  The closest command appears to be "Set all selected tracks to muted status," or something like that.  This of course requires selecting all tracks before calling this command.  I wrote logic into a button that would first "Ctrl A" on the keyboard to "select all" and would follow that logic with a command to "Set all selected tracks to muted status."  I then tried to add a "Ctrl Shift A" command that would also deselect the tracks afterwards (to mimic Sonar's "Mute All" button), but I could never actually get it to fully work.  I had to eliminate the "deselect" part of my logic and am left with a button that doesn't work unless I actually have the track view in focus too (I'm sure I need to add a focus command to the logic).  Is there any simple way you know of to implement a "Mute All Tracks" button that works as cleanly as Sonar's mix bank button does? Thanks, AZ!

Some possible operations are still have not found a place in AZ Controller. And that was one of it. Thank you for pointing.

Please download the latest version. Use "Strip" "Track" "First"(not used) "Rude Mute" to select the "parameter". Use "Value" "Toggle" to change the state. You can also Monitor the Parameter Value. "127"/"0" have the same meaning as on the mix bank ("127" when something is muted).

Very cool, indeed, AZ.  Works like a charm!  I'll definitely keep thinking about potential things that could be beneficial to a preset.  Until then, I have another "exercise" for you.  I seem to be having trouble setting states from parameter value or state monitor feedback sections.  No matter what conditionals I put into the feedback section, no "set state" action ever seems to take effect.  I have only encountered this problem when trying to set state in a monitor feedback section.  All the other set state actions seem to work as expected.  Thanks for your help, Alexey!

Something else I should add to this topic...

Whenever Sonar is fully closed and then reopened, all software states that I have programmed revert to default state.  In my case, this sets all states to "Off."  Unfortunately, if I save a file with any of these states set to "On," the logic will be broken when I close and reopen the file.  The reason this monitoring is important for my setup is because of the "Mute All" button you helped me create; it becomes impossible to keep track of the individual tracks' muted states if more than one button can change these states.  Without being able to trigger a state change based on a parameter value (and also do it instantly the moment Sonar starts), the current best implementation of a "Mute All" button will leave me occasionally having to press an individual "Track Mute" button more than once to toggle it back to the correct state.  Sorry if this is not making sense.

Here's a quick example.


• 
  I open a file with no muted tracks. The "Mute All" button has a value of "0" and my individual "Track Mute" buttons all have values of "0."
• I press the "Mute First Track In WAI" button.  "Value" is set to "127" and "toggle value" is set to "1.00." Track 1 is muted within Sonar. The next "toggle value" for Track 1 will be "0."
• I press the "Mute First Track In WAI" button again. Toggle for the first track is now set to "0" and the first track is now unmuted.  Next "toggle value" for Track 1 will be "1.00."
• Now, I press the "Mute All" button.  All tracks become muted. All tracks remain with "toggle value" of "0."
• I press the "Mute First Track In WAI" button once more.  Oops! Toggle value for first track now becomes "1.00." A 1.00 value in these circumstances means that the track has been set to "mute on."  But since all tracks were already muted,  I have just told track 1 to mute twice in a row.  This button press does nothing but "catch up" to the value it already was.
• I press the "Mute First Track in WAI" button one last time.  Track 1 now becomes unmuted.

Without being able to change states based upon values in the "feedback" tab, I'm afraid I will never actually be able to monitor the state of individual track mutes and will always have to press buttons multiple times to "catch up" with their actual states.  Thanks, AZ!

With "Toggle" there was a logical bug. It should be fixed now (please download the latest version). Thanks for reporting.

The problem was introduced with "smart" way to use the last set parameter as "current" under some conditions... So, after you have used "Mute all", particular "Mute" could see that while it has tried to change "Mute", it is still the same as before the attempt. So, according to the (wrong in this case) logic, it was using last set value as "current" (instead of real current). All that make no sense for Toggle, it is there for endless encoders. I am still not sure the algorithm is working fine in both (normal and endless) cases, please report any unlogical observations.

About setting state in Feedbacks. You can use "Set engine state" flag to really change the engine state in addition to the monitoring state. Please note that "Set engine state" flag in normal Logic list has different meaning (it also set the engine state, but it does NOT change monitoring state). It sounds complicated and in fact it is. Logical actions have really 2 contextes of execution, normal (when you engage the control) and monitoring. During monitoring, all these actions are changing temporary states, imitating what WILL happened in case the control is engaged (but since that has not YET happened, they do not do "real" changes). Monitors (feedback) actions are executed in that temporary states context. So, they see what WILL happened and can use that information NOW. So by default Monitors are also working with temporary states.

In some situations it is desired to change that default (so monitor wants to change real state), so the flag is there. But I do not see the need in you case. A preset should be constructed such way that it always "adopt" to current situation. I understand that with the toggle bug in place, there was no other chance to implement correct muting as monitoring mute value, setting (real) state and using it to change Mute manually (On/off instead of toggle). But the bug is fixed (I hope).

Just checked it out. I have been ferociously trying to break the toggle button again, and I'm happy to report that I cannot!  As you stated, there is no need for any sort of "real" state changing now that the toggle value bug has been fixed.  Here's to you, AZ!

I think I'm trying to implement a function that isn't currently possible with the current configuration of AZC.  I was wondering what you thought about this particular situation and if I should move on to a different implementation.

The Problem:

My control surface is currently set up to control 8 channels strips at a time.  Each channel strip has 2 corresponding pads that serve to control various aspects of the channel (Mute: On/Off, Input Echo: On/Off/, Record Arm: On/Off, and Solo: On/Off), and each of these 2 pads has LED backlighting which I can use to indicate the state of the current channel strip.  The pads are vertically aligned at the bottom of each channel strip (one pad above the other).

Between the 2 pads that I have per channel strip, I want to be able to visually indicate any combination of these 4 states at all times.  For the sake of our example, I want to only focus on one of these pads since I can easily translate the logic between them. 

On the upper pad, I am controlling Input Echo and Record Arm for the corresponding channel.  When the pad is not shifted, Input Echo is activated for the track.  When the pad is shifted, Record Arm is activated for the track.  When Input Echo is "On" and Record Arm is "Off," the pad color is set to green to reflect this status.  When Record Arm is "On" and Input Echo is "Off," the pad color turns red.  But the problem comes when I want to indicate that Input Echo and Record Arm are both on.  In this instance, it would be desirable to have the button change color to orange to reflect that both Input Echo and Record Arm are currently active for the track.

I can't use a parameter value monitor in this case because one button is keeping track of two states.  Having it look simply for Value "0" and Value "127" won't allow me to reflect a combined state.  I'm looking for something more like "Unshifted Value: 127" + "Shifted Value: 127" = SysEx "f0 ... f7."  The point is, I have to be able to store an extra variable to accomplish this.  In this case, I decided to implement state monitors for Input Echo and Record Arm on each track.  That way, I can give very clear lighting instructions to the control surface based upon the combination of states.  This solution works in most situations, but not all.  For example, upon project opening, if either of these states is active on any track, neither one will be reflected on the control surface because states are being monitored instead of parameter values.  Also, if I use my mouse and click on the buttons themselves, no reflection of a state change will take place on my control surface.  It seems like parameter value monitor is the only way to properly track these tracks states on the fly, but I can't currently trick it into seeing a combined state.

Sorry for the weird explanation.  This one is tough for me to get across.  Thanks for any help you can give!

I think I understand the problem. So, the solution which comes in my mind:

1) you want all the time monitor both parameters, Input Echo and Record Arm. It is not possible in the button actions list since it is controlling one parameter in time. The monitor there is to indicate exactly that parameter, whatever it is at the moment. But that is not what you want. So, you remove Value monitors from buttons.
2) you need separate monitor for each parameter, so you create fake controls "Input Echo Strip 1", "Record Arm Strip 1" and so on, which use the same strip selection as in buttons but select exactly one parameter (all the time).
3) Then you define Software Set for each button "BtnColor_1" with state "Off_Off", "Off_On", "On_Off" and "On_On".
4) in Value Monitors you set the states (do not forget to set "Engine" flag there), taking current state into account. So, in "Record Arm Strip 1" value monitor you need 4 Actions instead of 2 "(Value:0, BtnColor_1:Off_On) -> BtnColor_1 = Off_Off", "(Value:0, BtnColor_1:On_On) -> BtnColor_1 = On_off", "(Value:127, BtnColor_1:Off_Off) -> BtnColor_1 = Off_On", "(Value:127, BtnColor_1:On_Off) -> BtnColor_1 = On_On". You do not need "Value:127 XX_On" and "Value:0 XX_Off" since the state is correct.
5) In addition to Value Monitors you also add State Monitors, one per state (button). You can add it at the beginning to "Input Echo Strip 1"  (before strip selection, it is state monitor). In each state Monitor you send SysEx based on  the state.

Set priority "1" to Value monitors and priority "2" to State Monitors. That way value monitors will trigger state monitors guaranteed during the same monitoring cycle. We could send SysEx just in value monitors (after setting the state), but that will produce a "color flickering".

How it will (should...) work, also at startup and mouse switching: value monitor check the value and set corresponding state, which in turn triggers state monitor; then state monitor send SysEx based on the state (which was set correctly by both value monitors). States Monitors are triggered on startup (as you can remember that was fixed), so SysEx is sent even in case State is equal to default (Off_Off). Priority makes the procedure order predictable (so, check both values before sending SysEx, otherwise something like Input Echo=On (Record Arm=Off as not yet checked) can trigger false color till (next cycle) Record Arm is checked, introducing some "color flickering" after initial preset load and strip bank changes.

For 2 pads on 8 strips which control 2 parameters each you will need 8x4=32 extra controls, 16 state sets and 32+16=48 monitors. Just for 16 buttons. It sounds like a lot. But since you want 32 parameters parallel indication, the overhead is x2 only. I do not think I can optimize that. And you get some functionality no one had before in SONAR :)

The overhead is minimal, indeed! Your solution makes perfect sense, and I really appreciate you taking the time to explain it to me.  My control surface feels so independently functional right now.  Yet another reason I love this software and find it so powerful.  The less I have to look at my computer screen to know exactly what is going on, the better.  Thanks, Alexey! 

I want to mention one possibility which is not yet implemented in AZ Controller, it stay in TODO list but for the moment with low priority. In case you think it can be useful for you, I can implement it.

API supports strip level monitoring. In case I implement "Track X monitor to value" action, by mapping the result to state set and using it for colors it should be possible to display on pads either there is no signal, some signal, loud or clipping. I can also make special function for clipping only (and reset clipping).

I'll say this: If you boost it on your priorities, I'll definitely have a lot of fun integrating it into my setup.  However, this falls fairly low on my current needs list since I'd be most likely to use it for visual excitement.  I do see a lot of potential for interesting functions upon clipping, such as pausing playback and focusing the offending track (or even audio or midi clip?) and giving informative visual feedback to the control surface.

Perhaps this warrants discussion of a related topic.  I recently completed an 8 fader setup where each fader has a parameter value monitor on it.  For every discrete value of the fader (0-127), I triggered a SysEx message to my control surface to change the color of an LED.  Each fader has its own assigned LED.  This gives a relatively smoothly transitioning color change from dull green to bright red as the fader reaches a certain level.  I found it was important to have 128 values for each fader since "Ultra" monitor speed is approx. 13 times per second, few enough to introduce noticeable skipped values when moving a fader at an average speed. 128 values also allow for smoother color transitions.  The LEDs serve as good visual indicators of each track's relative position if I happen to move the WAI position and then change any fader orientations.  I personally find that dangerous volume levels on tracks vs. busses and mains tend to be pretty different.  I stay away from boosting tracks above -6db by too much, while a buss or a main that has been accidentally boosted above 0db doesn't usually cause dangerous volume jumps.  For this reason, I use 128 different values for busses and mains. All told, for each fader, I have 256 distinct SysEx messages.  This brings up 2 points:

1.  Is this a practical usage of AZC, or could it introduce problems? If it is indeed an acceptable usage (hasn't caused any problems here yet), then issue 2 might have some relevance.

2.  When I went to program each fader, I had to change 256 messages each because one hex value in each SysEx string is used to determine which LED is triggered.  8 faders x 256 messages was 2048 lines of code requiring editing of one hex value.  Since I would likely eventually use strip level monitoring to trigger some LED indication, I can see myself doing this again.  However, I suspect that implementation of any fancy hex pair editing for SysEx commands is probably even further down your TODO list than strip level monitoring.  Just thought it might be worth noting.

Overall, I would use strip implementation, and I'd probably be more than happy to go through a few thousand lines of code again to push out some LED flair to top everything off.  But I don't think you should rearrange your priorities just yet.  I've actually got to set aside a good chunk of time to squeeze every bit of functionality I can out of my ACT controls.  It'll be a good bit of time before I tinker with strips again.  Thanks a bunch for offering!

I decide that I want level indication myself, so it is already implemented :) Related tutorial will be published in a minute.

Sorry for not proposing that before, I can hardcode additional PSS (Program Specific Send) which can be parametric. Please remind me which controller you use (direct link to the documentation is even better) and describe what mapping (value->hex parameter) you want. No problem with that, really.

About 13 times per second... It is fixed inside SONAR. But you should take into account other timings. MIDI standard is old, one SysEx can take several milliseconds. Also I have seen that all my devices are not really sending each change to computer, they accumulate/skip them.  You can check with MidiOx or other monitor either your faders are really sending smoothly, most probably not.

The performance of my plug-in is not optimized yet. The plug-in is written in plain C and action conditions check is one loop with just several CPU commands inside so I guess much more then several thousands actions is required to produce some performance impact (the loop is executed with GHz speed while time quantization is in kHz region). In code, there is no limit on number of states/actions/controls/etc.

Driving home I got awesome idea how we can smooth the color response from faders.

In fader control we can not get new value from SONAR, but we have the value from control itself. So we can use it to call color submission without waiting next refresh cycle (~0.1sec).

But we should check that the value is really used in "Catch" mode (I assume you use it instead of "Direct") since we do not want change indication till the fader is in position. And such detection is not possible in current version... I have to implement it.

Fascinating idea.  I wish I had the proper knowledge to understand exactly how it would work, but it sounds cool.  My background is actually Computer Information Systems and Management of Information Systems, so it's really fun trying to understand the thought process involved in this kind of programming.

Can't wait to try out some strip level monitoring functions!  Thanks a lot for coding that functionality!  The possibilities here coupled with some streamlined SysEx handling is going to help quickly implement some useful visual indications on my board.  I'm using a Novation Launch Control XL.

Here's a link to the programmer's documentation.

http://d19ulaff0trnck.cloudfront.net/sites/default/files/novation/downloads/9922/launch-control-xl-programmers-reference-guide.pdf (http://d19ulaff0trnck.cloudfront.net/sites/default/files/novation/downloads/9922/launch-control-xl-programmers-reference-guide.pdf)

To summarize the information for you a bit, SysEx messages received by the Launch Control (that most users will be concerned with) will likely be some form of the "Set LED" SysEx command which adheres to the following format:

F0 00 20 29 02 11 78 Template Index Value F7

"Template," "Index," and "Value" are variable hex pairs in the command, with "Index" and "Value" being the primary ones that get changed.  "Index" denotes which LED will change and "Value" denotes the color.

Thanks again for looking into this.

Cheers! 

After checking the documentation and analyzing you use case, simple parametric PSS is not going to help till is it too specific for your (current) use case. Not nice.

Please correct me in case I am wrong, but you try to highlight 2 strip pad based on fader value. You have 2 pads, 2+2bits=16 colors per pad ^2=256 color combinations. The mapping is not linear, since bitwise it will Red->Green->Amber->Green->Amber. And Green->Amber->Red  sounds more logical for me. But at some point you (or someone else) would like to change the scale or use different scales for different cases.
Also it is better to send both colors in one SysEx to save time (there is some indication that can be slow, they mention up to 0.1sec to update all LEDs and I have the feeling that is not maximum).

So, I think about extending SysEx action to allow build it in peaces. That way the list of actions is going to be:

• 2 State Sets: "_LowerColor" and "_UpperColor", with 128 states each which text correspond to the proper color value in hex for particular input value (can be up to 256 states but also lower then 128, so can be any number of states from 2 up to 256).
• 1 State Set "_StripIndex" with 8 states, text is the hex value for Index of lower set of pads
• In the Fader Value Monitor, we just do:
  
  
  • Set State _StripIndex to <whatever is correct for the strip state>
  • Call _UpdateStripColor
• _UpdateStripColor (only one for all strips, can also be used later for "smooth" indication mentioned in my previous post) is going to be:
  
  
  • Set State _LowerColor <from value>
  • Set State _UpperColor <from value>
  • SysEx BEGIN (F0) 00 20 29 02 11 78 and either hardcoded Template or some State Set
  • SysEx APPEND _StripIndex name +0
  • SysEx APPEND _LowerColor name +0
  • SysEx APPEND _StripIndex name +<fixed number difference between lower and upper pad ids>
  • SysEx APPEND _UpperColor name +0
  • SysEx END (F7)

Not controller specific, not current wishes specific, support arbitrary number of colors and arbitrary color values, reasonable in size for all that wishes and opens a way for similar operations. Looks cool for me  :)

Unfortunately, we have long holidays there and I will dedicate my time to the family. So that is not going to work next days, sorry.

QuoteMy background is actually Computer Information Systems and Management of Information Systems, so it's really fun trying to understand the thought process involved in this kind of programming.

I have caught the end of time when System Programmers was looking at userland coders like the god on worms. First could find broken memory module from the system dump in hex, second was happy when "print 2+2" was working. Good old times...

But now everyone is a "programmer", at least in HTML.

Behind AZ Controller are around 30000 lines of C code. I have tried to explain how that works as far as I could, but complete explanation will take at least another 30k lines. In big blocks, it has MIDI parsing engine, custom "language" interpreter and GUI part which is more or less IDE for that language. The ideas have roots in many systems/languages/interpreters I have worked with. The primary inspiration and basic concept of self-contained programming system is for sure FORTH (http://en.wikipedia.org/wiki/Forth_%28programming_language%29). For me, more usual concepts like Lisp (CAL in SONAR) do not have that simplicity, flexibility and power.  It was clear for me that anything above my Programming for Musicians (http://www.azslow.com/index.php/topic,11.0.html) is not going to work at all. Most user heads are exploded even by that. And such things like reverse Polish notation and stacks can "reboot" some "programmers". Still I could not avoid some complicated concepts like state specific object execution (compilation, interpretation and immediate) have "leaked" into AZ Controller (Actions have Logic, Monitoring and Feedback execution methods). But I have tried to wrap them into "natural" effects. Originally I have planned to avoid even "functions", but I see that in complicated configurations (like your) that is not practical. In case you have some specific questions, I can try to answer  ;)

I hear you about everyone being a "programmer" these days.  That's why I avoided even using the term to describe myself.  My experience ends at programming and deploying a simple Java encryption/decryption application across a network for users to send a receive simple encoded messages.  Hardly makes me a "computer scientist."  Familiar and comfortable with small scale OOP projects.  I was actually just trying to get a grasp on the idea you had to potentially improve color response (There's no way my brain could grasp the underlying logic of AZC itself!).    ;)

On the subject of the controller specific colors, you are correct in that the mapping is not linear.  I am actually only triggering one LED (not a pad, slider, or rotor, but a plain LED) per fader, so there's no need to send two SysEx messages in my case.  Believe it or not, with a lot of trial and error I was able to create very acceptable, damn near smooth transitions from color to color just by triggering SysEx messages with the current setup.  There are other color values not listed in the documentation that help these transitions.  Since each fader has a simple value monitor in place with 128 potential values, it's not really an issue of overhead at all, if I understand correctly.  I was basically just looking for a way to copy the feedback logic of one fader to another fader and then change one hex value all the way down the list of 128 SysEx messages (to send the color feedback to a different LED).  This way each fader affects its own specific LED.  As it stands, it's not too bad changing the values by hand (and once its done, its DONE), and I don't want to distract from more important functionality.

That said, enjoy your vacation and family time!  That's way more important than any of this.  Thanks again for your thoughtful explanations and help!

Well, I had to babysit my daughter today. So I have implemented the feature.

So, in your simplified case, you need "_Color" state set with 128 (or less) states. Names of of the states should be hex values (like "05", "7a", etc). "_StripIndex" is still required. The content of  "_UpdateColor" Control (one for the whole configuration) is going to be:

• Set State _Color <from value>
• SysEx Begin (F0) 00 20 29 02 11 78 and either hardcoded Template or some State Set using the same approach as with _Color/_StripIndex
• SysEx Append (_StripIndex)+0
• SysEx Append (_Color)+0
• SysEx End (F7)

And in the Fader Value Monitor, the action list is (per monitor):

• Set State _StripIndex to <whatever is correct for the strip state>
• Call _UpdateStripColor

You still need the state set with up to 128 color codes. But the action list is much simpler and you get quite some flexibility, for example you can use different _Color sets in different situation, use the same codes for other LED's, etc.

Do not forget that you define states from the end (so, the first defined value is going to be for 127). Reworking the set in case of a mistake can take some time.

So, in the latest version, you can smooth the color response from faders by inserting:
Last Action: OK -> Set State _StripIndex to <whatever is correct for the strip>
Last Action: OK -> Call _UpdateStripColor
right AFTER the Value Action. If you have Monitor actions after Value and no actions between Value and Monitor, you can insert that after Monitors. That will save some CPU cycles...

How it works: "Last Action: OK" checks that Value is really setting new value. In case of "Catch" mode, Value will return "Failed" till the control is in operating position. And the current fader value is used (instead of converted real value, as in Monitor) to set the color immediately on control operation (without waiting 1/13 of second).

Theoretically, non linear response curves should work as expected (when Value Monitor converts real parameter Value into 0...127 MIDI range, it takes that into account). So, direct color set and Monitor color set should be the same. But that was not intensively tested by me.

Oh boy!  You rock, Alexey! Can't wait to try this all out.  Been dealing with some medical issues here, so I've taken some time off from doing anything musically related.  I'll let you know how this works out for me the second I get a crack at it.  Thanks again, AZ!

Health should take priority over music. Many examples of what can happened otherwise.

I have planed like 8 visits to different doctors next weeks as well. Nothing serious, but some my components are aging and should be checked/fixed  ;)