Selecting a particular track within WAI

[azslow3]

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).

[SonarHatesMe]

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!

[azslow3]

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.

[azslow3]

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.

[SonarHatesMe]

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

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! 

[azslow3]

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.

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.

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. 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 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 

[SonarHatesMe]

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!

[azslow3]

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.

[azslow3]

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.

[SonarHatesMe]

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!

[azslow3]

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