Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 6 of 6

Thread: I am looking for some help with a very sensitive quadratic encoder wheel.

  1. #1
    Junior Member
    Join Date
    Jun 2017
    Posts
    14

    I am looking for some help with a very sensitive quadratic encoder wheel.

    For the last year I have been working on a project to convert faulty pioneer cdj 800 and 1000 to midi devices using teensy 3.2 and 3.6.

    https://www.youtube.com/watch?v=bT6g...lt-0IqBr6Gwxkd

    I made a full series of videos showing how to wire mod a faulty unit and now designed replacement PCB that can be swapped over. I am working my way through testing and optimising each part and I am struggling with reading the encoder on the jog wheel. It works, but it's just too fast and I have to reduce the sensitivity in Traktor down to 15%. This still has some problems when I move the jog wheel very fast, but I think that is down to traktor and the reduced sensitivity setting.

    I looked at the encoder.h and have tried changing the case select so it only responds to 2 states and not the 4 from the original and this helped a lot, but it's still way to fast. How can I reduce the number of midi commands I send from moving the jog wheel without missing the steps from the encoder wheel.

    Code:
    switch (state) {
    			case 1: //case 7: case 8: case 14:
    				arg->position++;
    				return;
    			case 2: //case 4: case 11: case 13:
    				arg->position--;
    				return;
    			case 3: case 12:
    				arg->position += 2;
    				return;
    			case 6: case 9:
    				arg->position -= 2;
    				return;
    		}

  2. #2
    Junior Member
    Join Date
    Jun 2017
    Posts
    14
    I am trying some simple code that counts up to a set number before sending the midi command and it seams to work. I can adjust the setting on the tft screen and I have found waiting for 8 movements from the encoder before I send the midi and then 50% sensitive in Traktor gives me the feeling I want to replicate using CD on the original CDJ 1000.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,363
    Wow, nice work on the video!

    Yeah, if the encoder has a lot more resolution, the solution is usually to divide the results by some constant.

  4. #4
    Junior Member
    Join Date
    Jun 2017
    Posts
    14
    I really would like to replace the simple quad encoder from the original cdj with something I can track the actual position, but if I want to make kits to sell at some point it would add to much to what I need to produce. The teensy can keep up with the signals no trouble, it just sends way to much data to the dj software so with some different gearing I could also solve this problem.

  5. #5
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,297
    You can limit by time rather than magnitude.

    An elapsed time since previous sent message can be checked and a new message sent only if some minimum threshold time has elapsed.

  6. #6
    Senior Member oddson's Avatar
    Join Date
    Feb 2013
    Location
    Isle in the Salish Sea
    Posts
    1,297
    Quote Originally Posted by oddson View Post
    You can limit by time rather than magnitude.

    An elapsed time since previous sent message can be checked and a new message sent only if some minimum threshold time has elapsed.
    I guess that depends on what you are actually sending... I guess you are generating timing codes then not so much...


    In my defence you didn't really spell out what you are doing.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •