AAO is reading left and right when turning my 8th encoder on my X-Touch Mini in one direction. When setting up an assignment, it is bouncing back and forth between CHN: 11 EVT: 3008 TURN_RIGHT and TURN_LEFT as I turn it one direction. Meaning when I turn it left, it randomly detects left and right while turning it. If I turn it right, same thing. I thought maybe the encoder was bad. Tried cleaning it first, but no change. Then I went ahead and bought a new encoder on eBay and soldered it on, but the behavior is the same. I just downloaded MIDI-OX now to test it. When I watch the console, the data coming from the encoder shows as expected. It is showing data only from the direction I'm turning it, not back and forth. Why would AAO have a problem reading this encoder? Is there some way to get debug output from AAO to see the raw data from my device?

Sorry, never heard of something like this before. No clue. And, no, there is no log output, because AAO does not process raw MIDI data. It uses a library that is event driven: whatever comes in over the MIDI stream, AAO is only informed of the actual event (NoteOn/Off/CC/etc.). 

Is that when you assign it or when you use it? Assignment and actual operation are two different mechanisms. When assigning an encoder, make sure that you don't turn too far. Put the encoder in the middle, then turn it left one notch until it says LEFT TURN. Save immediately. Same for right turn.

Also, make sure that the device isn't in MC mode. Did you reset it to factory defaults?

Edited January 16Jan 16 by Lorby_SI

I experience this behavior regularly, and it comes down to perhaps the first step that you're supposed to do when programming A&O. I am going by memory, so my  apologies if I get this wrong.

If I press a midi button before I declare what kind of button I am pressing, I think A&O behaves badly. I think you need to press the "rocker" radio button and then move the midi dial either left or right in order for the correct direction to stick. 

 

Thanks for the reply. It happens while assigning and while using. I can get it to assign Left and Right if I move it one click yes, which is how I got it assigned originally. The other encoders don't have this same sensitivity. I did try a factory reset using the X-Touch editor a couple weeks ago. I loaded the default bin files. I do not use it in MC mode. It's quite strange. Like I said the other encoders and buttons behave (assign and work) as normal.

I've had this issue for many years. Sometimes, I have to totally delete the button assignment and start from scratch, which happens to erase(reset) whatever is making it misbehave. There's definitely an issue; it's just hard to record it and analyze it in order to seek a solution or provide evidence of the problem.

8 hours ago, flyforever said:

There's definitely an issue;

The "issue" is that MIDI is not a game controller protocol, it is sending musical notes with different velocity values (=volume). AAO cannot know if you are turning it right or left,  because there is no information about that included in the protocol. The app has to calculate that from the velocity values that are coming in. If the velocity gets higher, then you are turning right, if it gets lower, you are turning left. Problem is, that there are only 127 velocity values, so turning an encoder round and round is technically impossible. When you have reached 0, all that the X-Touchs sends are zeroes. Same for the other edge 127. But at least it is sending those, there are controllers (Korg) that just stop sending data. On the XTouch AAO assumes that when you were turning right previously and AAO gets another 127, you apparently continue to turn it right. 

Anyway, it is very important that you center the encoders before assignment, and then only turn them in the required direction for as long as it takes for it to show "TURN LEFT" or "TURN RIGHT" (usually two clicks). Then save the assignment. 

In actual operation this shouldn't be a problem, only in assignment.

Also, be careful when you try to operate the LEDs, make sure that you don't get conflicts on the MIDI channel. Do not use the same channel and asset (Note/CC) for input and output at the same time. Some people do it, but this never worked for me. I am always using the X-Touch reset to factory (hold down Layer A+B buttons, unplug and replug the XT), where everything is sent on channel 10 and received on channel 1, with different MIDI controls for input and output.

Edited January 17Jan 17 by Lorby_SI

Thank you for providing a clear, technical explanation regarding MIDI and A&O.  A&O is one of the best utilities for button assignments.

1 hour ago, flyforever said:

Thank you for providing a clear, technical explanation regarding MIDI and A&O.  A&O is one of the best utilities for button assignments.

Some more info:

- when you are using more professional MIDI controllers, make sure that the buttons are not velocity sensitive, or turn that feature off. Velocity sensitive buttons would behave like an encoder, because they don't just send 127 for down and 0 for up, but also all values inbetween, depending on how hard you hit the button (for example Ableton Push, Native Instruments Maschine, etc.). In AAO you would get LEFT_TURN, RIGHT_TURN randomly, instead of CLICK

- The "Rocker" option on the other hand is for controllers where you can't turn the encoders endlessly = that have physical stops on both ends of the scale (Korg, Akai). In that case you can assign the encoder in such a way that you always turn it left or right only a few clicks and hold it there - and AAO will repeat the associated command until you put the encoder back in the center position.

Thanks for your replies. I discovered it was my aircraft automated script, for setting LEDs, specifically for that encoder, causing the problem. Turns out the behavior is also fully explained by Funatic in the post below, about the negative consequences of using the same channel for button assignment and changing LEDs. For that encoder I was using channel 11 instead of Global channel 1 because I wanted to also be able to control encoder LEDs on layer B. And it works for the LEDs, but causes the strange behavior noted above. So controlling encoder LEDs on layer B requires a different strategy, which I'm not going to bother doing at this point. There is a free framework of scripts on flightsim.to that enables this, but I'm not going to reprogram everything now that 99% of what I have is working as desired. Thanks all for the assistance.

 

Edited January 17Jan 17 by ParadiseFlight