You can use a variety of encoders and that's what I did with my experiments.
That schematic I did is incorrect in the cap/resistors for the debounce circuit. I think the HIGH signal is debounced, but the LOW signal isnt. I must have changed values several times while jacking with it for best results. It really needs to be abandoned or perhaps a note of warning.. I dunno.
I tried 30ppr and 20ppr encoders. They are standard for the most part. 30ppr is too many short pulses in one revolution, that's why Circuitbenders used a 20ppr encoder. It's slower with a longer pulse.
You cant even click the buttons faster than a certain speed.
To put in a encoder with only hardware would be very frustrating and if I had paid for a kit(which I basicallydid when I bought the parts I used), I'd be very disappointed.
It's those larger values like 0-99 for filter and other high value parameters that you'd really want to tweak quickly that really need firmware based decoding of the encoder.
I built one, spent DAYS on it and I was so disappointed that I finally gave up on it and deemed it unworthy to pursue any further due to the pulse/scan issue that I came to realize was the problem.
Mike, I believe doing a bit of code magic to the firmware would allow a much more useable knob.
The Kawai K3 keyboard used a very simple encoder circuit that the uC decodes.
Take a look at the schematic sometime..
http://www.soundprogramming.net/manuals/Kawai_K3_ServiceManual.pdfpage 9, upper left corner is the encoder and debounce schematic w/DDFF.
Looks like one signal is untreated by the FF and the other line is processed by the FF.
I think it's a ~25ppr encoder. Works nice, but takes a few full turns to do 0-99. They provide a very nice knob with a "finger dimple" in it to help spin it evenly/without stops.
there are very nice HAM radio knobs out there with spinner knobs to grab a tiny handle to keep it spinning w/out stops. This is the best method, but are expensive.. $12+ for one.
I bought a nice 1 1/4"d x 1"h knob with a small finger dimple in it for $4 instead
Mike, I liked your idea of sampling the rate of change to perhaps cause the change to be more logarithmic vs. linear, depending on how fast you turned the knob.
And I think maybe there's a way to load data to a algor. to process the rate according to the size of values to change. Like each time you select a parameter, it loads that param's value range into the Wheel's algor. Or is that too much to process on each update?
I'd love to help create a great Data Wheel for the HAWK..
Anything I can do to help? I have plenty of parts/veroboard etc. to build prototypes.
-Blaine