Selecting a particular track within WAI

[SonarHatesMe]

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!

[SonarHatesMe]

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.

[SonarHatesMe]

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.

[azslow3]

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.

[SonarHatesMe]

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!

[azslow3]

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.

[SonarHatesMe]

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!

[azslow3]

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

[SonarHatesMe]

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!

[SonarHatesMe]

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!

[azslow3]

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

[SonarHatesMe]

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!

[SonarHatesMe]

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!

[azslow3]

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

[SonarHatesMe]

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!