Rapidly-fluctuating output when using rotary encoders with Raspberry Pi + Processing

Question

I'm using a Raspberry Pi 3 with some Cylewet KY-040 rotary encoders that I bought from Amazon to set up an art installation with Processing 3. Pi is just running the stock Raspbian NOOBS.

Right now, I'm trying to to adjust the radius of a circle with one of the rotary encoders, but the radius value is rapidly fluctuating from -1 to 1 with each turn/"click" when it should be increasing or decreasing by 1 depending on the direction of rotation.

I am VERY new to Processing and coding a Raspberry Pi with GPIO, so I'm not sure if this is an issue with my wiring or with the code :P

I wired up my Pi by following the wiring diagram here: https://www.modmypi.com/blog/how-to-use-a-rotary-encoder-with-the-raspberry-pi

My code is my interpretation of this tutorial converted to Processing using the best of my ability.

import processing.io.*; 

int clk = 17;
int dt = 18; 

int counter = 0; 
int clkLastState = GPIO.digitalRead(clk); 

void setup(){
  size(500, 500); 
  GPIO.pinMode(clk, GPIO.INPUT_PULLDOWN); 
  GPIO.pinMode(dt, GPIO.INPUT_PULLDOWN); 
}

void draw(){
  int clkState = GPIO.digitalRead(clk); 
  int dtState = GPIO.digitalRead(dt); 

  if (clkState != clkLastState){
    if (dtState != clkState){
      counter = counter - 1; 
    }
    else {
      counter = counter + 1; 
    }
    println(counter); 
    delay(500); 
  }
 clkLastState = clkState; 
 ellipse(250, 250, counter, counter); 

}

I have experimented with the delay() and it hasn't helped much to slow it down, as the values are just as incorrect, but print more slowly.

The values printing to the console are kinda accurate-- the circle's radius does match what prints to the console. Ideally, the console should be printing counter + 1 when rotated clockwise and counter - 1 when rotated counterclockwise, however...

when turning the encoder clockwise only, the radius values are printing to the console as follows:

1
2
3
2
3
4
3
2
1
2

A similar result is produced when turning the encoder counter-clockwise, but with negative values:

-1
-2
-3
-2
-3
-2
-1
0

Note: when I turn the encoder slowly and lightly pull the rotating knob on the encoder, I am able to get closer to the result I want.

Answer 1

For anyone who has the same issue, I found a great, working solution written by GitHub user Arty2 here: https://gist.github.com/Arty2/ab77038addb7f40163ba

Apparently, Processing does not support pull-ups, so some bit-shifting is required.