The Marker fix worked perfectly, and while I was at it I also change the go to next marker to it's respective native function and that works better as well, it is faster to go the next markers like it is natively.  Thank you so much, I will test the fader now.

The fader works!!! with fix from post#86 no more fighting back

Thanks! I will include it into the next update.
 
I hope that I can also solve the problem with disconnecting.

https://youtu.be/VtJ4ymXJRHE
 
In this test I try not sending midi out to the AlphaTrack in an attempt to show whether the screen update data causes the dropout.

Thanks! That mean I have to reduce the information I send to the display when you operate controls. I will make the modified version tomorrow and let you know. But you can help with good approximation: compare how fast AZ Controller update display with the speed of original plug-in. Can you notice some difference?
I am going to reduce data flow by half in any case (I always send upper line as well, while it is not changing in this mode), but may be I also have to reduce update frequency.

I just played with it and noticed some differences. First, when rotating the pot to change the pan, the original moves like 10-12% with each click, so quite quickly.
Yours moves 1% per click, so quite slowly.
 
Also, when the pot is double-clicked on the original, it resets the pan position to center. This is generally true. A double click resets the item to its default position.
 
So, while the update seems quick, because the movements are in larger increments, it is probably that the amount of data sent is less.

Like in the original, there are two resolutions for the encoders (Pan, Send, everything else) - you click once to change between them. The selection persists on a per-encoder, per-mode basis. The original has a little asterisk in the display to indicate that the control is in fine-resolution mode; Alexey tells me he's working on updating the display code to get something like that working.
 
The double-click to reset to default value is a nice touch, I'd forgotten that and maybe it's not in the documentation. Possible, Alexey?

gswitz
I just played with it and noticed some differences. First, when rotating the pot to change the pan, the original moves like 10-12% with each click, so quite quickly.
Yours moves 1% per click, so quite slowly.

It is ~0.8% per click (1/127). Playing with endless encoders I have also noticed that does not works as fast as normal knobs with the same resolution. I am thinking to add more resolution choices then MIDI(127)/Fine(1000) as I have now. But 10-12% means you have like 9 positions for pan (left, center, right plus only 3 in between on both sides). Is original behavior so quantized?
 
I also plan "software acceleration" for encoders, like used for mouse moves.
 

Also, when the pot is double-clicked on the original, it resets the pan position to center. This is generally true. A double click resets the item to its default position.

The documentation was not explicitly mentioned that (or I have overseen). I understand now why Coarse/Fine is done be "press and turn" then, in case "press and press" is used to set default, "press" alone is not nice to use for anything.
 
Here are 2 problems: AZ Controller does not support "double clicks" yet (and I do not like the idea even for mouse), Sonar is no help with the default value for parameter. So what that default is for each controlled parameter has to be somehow "hardcoded". For 1-2 cases, like "Pan", that works. But not in general.
Original MCU plug-in has special (independent from ACT...) files with parameter mapping, including native "step" size and default value. Per plug-in per parameter. What I mean is that CakeWalk knows it is handy since 10 years...
 
So, sorry. This feature will be not available in the near future.
 

So, while the update seems quick, because the movements are in larger increments, it is probably that the amount of data sent is less.

No, the amount of data is still the same. But I have asked to compare display updates, not values updates. That is what influence the amount of data sent. At the moment, it is up to 13 times per second and it looks like AT is not able to handle that.

Hey Alexey.
 
Yes, in the Frontier plugin the 'normal' encoder resolution changes Pan (for example) at 11% per click, thus 9 clicks will take you from center to full right or full left. The 'fine' resolution seems to be between 1% and 2%.
 
I feel like it's not really necessary to make it exactly the same as the original plugin, since that was just some programmer at Frontier's best guess as to what would be useful. If people have gotten used to it, they will notice that it's a bit different in your plugin perhaps, but that doesn't necessarily mean it was better - I think the point should be to make it efficient to dial in a precise value quickly. I think if Fine resolution were 1% and Normal something like 6%, it would probably be best - I think turning from center to full pan should be accomplished in one twist, which is not possible with your current Normal resolution.
 
More resolutions might work, but would also add complexity so I'm not sure it's really necessary and might not really improve overal user experience; I think trying to find the optimum two values would be better. Personally I find the Frontier values a bit too coarse, and your current values perhaps a bit too fine, so somewhere in the middle (as per my proposed values above) might be the sweet spot... I would experiment with different values myself, but I can't (yet) figure out where they are set. In the Logic tab they are just referenced - 'RightRes. Pan:Normal', 'RightRes. Pan:Fine' and so on.
 
With regards to double-clicking for parameter reset, I agree it's a can of worms that might create more problems than it's worth. But what about shift-click? Can we modify the encoder-click behaviour with shift? I know this is tricky at the moment as the shift functionality is already tied up with Trim. However, and I proposed this before on your site,  the entire Trim control could be moved to a second 'page' of the Pan mode, which would be more consistent with the way other modes work, and also free up shift-encoder-click for (maybe hard coded) Pan reset.
 
Whatever, just thinking out loud, hopefully it's helpful, maybe not... 
 
Finally, with regards to the update speed - it's odd that the frequency of updates should cause disconnects on one AT but not on others - I haven't had a single disconnect in all the time I've been testing your plugin, which is a lot (I am using it full-time in production at this point). So it's not quite true that the device can't handle 13 updates per second across the board. Either some units can (mine) and some units can't (gswitz's?) - or something else is causing the problem.

@Subtlearts,
 
While the double press might have been arbitrary, I believe it was created to fix the problem of not being able to return Pan to 0. For some reason in the original AlphaTrack Sonar Plugin it is hard to bring Pan back to dead center. It is always off a little. I think that is why they implemented the double-press return pan to 0.
 
I only ever used this feature on Pan, so to tell the truth I don't know of it works on the FX Bin faders which can have new default values set. I can try it for you, Alexey, if you care to know.
 
@Alexey,
I agree with Subtlearts that it doesn't matter if you implement double-press. I was only remembering the behavior. I was also noting the difference in granularity of the changes.
 
Alexey, I'm afraid we are putting you to a tremendous amount of work. I hope you are not pushing yourself too hard.