Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Buttons and encoders not reliable and laggy
#1
Hi all,

I've just started using my NDLR. I already received it back in November but I haven't been home for the past months. 

I quickly noticed problems with the responsiveness of all buttons. Pressed slow they seem to work. Pressed quickly (with light tap) they are very unreliable. The haptic feedback from the click does not at all mean the press is registered.

I can fairly quickly alternate between two buttons and more often then not the clicks are not registered. Switching quickly between two buttons is not something you might want to do, but I also get failures when I start pressing around the different modal stages and don't press down long enough, and that seems problematic to me. I do think you will get used to this after a while and learn to make each press firmly enough, but it I think it gives a bad overall feel to the hardware.

To me this seems like a software issue because it equally applies to all buttons. I'm guessing it's related to the logic scanning the button inputs and registering their state. I've started out using firmware that came with (.60?) it but now upgraded to the latest version. Both seem to behave the same.


I also noticed the encoders when turning are similarly laggy, seems like there's a delay of about 100ms between feeling the encoder increment/decrement and seeing the value on the screen change. Similarly to the buttons turning them quickly will result in unpredictable behavior. For example try to making a small turn back and forth on the pattern position. Although it might feel you're doing a similar range, the position will differ because the amount of registered incr/decr steps is fluctuating.

If the Teensy isn't already pushing its limits in terms of CPU cycles, I hope this behavior can be improved quite a bit.
Reply
#2
(02-23-2020, 06:30 AM)0x80 Wrote: Hi all,

I've just started using my NDLR. I already received it back in November but I haven't been home for the past months. 

I quickly noticed problems with the responsiveness of all buttons. Pressed slow they seem to work. Pressed quickly (with light tap) they are very unreliable. The haptic feedback from the click does not at all mean the press is registered.

I can fairly quickly alternate between two buttons and more often then not the clicks are not registered. Switching quickly between two buttons is not something you might want to do, but I also get failures when I start pressing around the different modal stages and don't press down long enough, and that seems problematic to me. I do think you will get used to this after a while and learn to make each press firmly enough, but it I think it gives a bad overall feel to the hardware.

To me this seems like a software issue because it equally applies to all buttons. I'm guessing it's related to the logic scanning the button inputs and registering their state. I've started out using firmware that came with (.60?) it but now upgraded to the latest version. Both seem to behave the same.


I also noticed the encoders when turning are similarly laggy, seems like there's a delay of about 100ms between feeling the encoder increment/decrement and seeing the value on the screen change. Similarly to the buttons turning them quickly will result in unpredictable behavior. For example try to making a small turn back and forth on the pattern position. Although it might feel you're doing a similar range, the position will differ because the amount of registered incr/decr steps is fluctuating.

If the Teensy isn't already pushing its limits in terms of CPU cycles, I hope this behavior can be improved quite a bit.
Hi 0x80, I'm sorry you're having issues. I'm fairly new to the team but I handle a lot of the support here lately. Let's see if we can get to the bottom of this. As far as the screen goes, I believe screen updates have a lower priority than more important internal functions and so may not immediately (as in milliseconds) reflect changes, so that part is less surprising to hear. I haven't experienced my NDLR noticeably missing button presses, so let's see if we can get mine to recreate what yours is doing there. Would you mind giving me a list of instructions to recreate the issue on my end.
I.e.:
1. do this for 3 seconds
2. now do the other thing etc.
The more specific the better.

Also if you could do the same for the encoder issue, maybe using one of the sub menus that has a lot of visual feed back like the pattern editor (lower left encoder moves the selected step to edit, that would be an ideal candidate). 

Let's go from there and once I can see if this happens on my end let's see if anything can be done about it. I can't promise anything, as there may be hardware limitations, but I'll do my best to try.
Yours,
Jesse Johannesen
Reply
#3
Hi Jesse,

I guess a video is the easiest way to show it. I've only done this for the buttons now:

https://www.dropbox.com/s/iuebjzh8yax9rr...7.mov?dl=0

Cheers
Reply
#4
(02-26-2020, 03:08 AM)0x80 Wrote: Hi Jesse,

I guess a video is the easiest way to show it. I've only done this for the buttons now:

https://www.dropbox.com/s/iuebjzh8yax9rr...7.mov?dl=0

Cheers
Hey 0x80, 
Darryl has informed me that the button issue is something we've noticed as well (I guess I just have heavy fingers), and that the click doesn't always coincide with the button registering. Unfortunately all production units have the same buttons, so replacing the board won't fix the issue. The solution is largely just pressing a little harder. We do apologize and realize that it takes some getting used to. Sorry man.
Jesse Johannesen
Reply
#5
I think I can get used to it. But did you mention to him that I suspect the scanning rate to be the culprit? Since all buttons behave similarly (2 different types + encoders) this feels like a software issue to me. If the scanning interval on the Teensy controller is not short enough, quick button presses will go unnoticed.

Pressing harder is also automatically pressing longer. So it might appear that pressing harder solves it but that is not necessarily correct I think.
Reply


Forum Jump:


Users browsing this thread:
2 Guest(s)