Professional gear often makes use of optical encoders. The resolution of the 'normal' mechanical encoders suggested by CrossRoads and Graynomad (24 pulses per revolution) is way too low when you are using large or medium sized jogwheels.
why is that filtering required? It's just a digital input. I'm using the above encoder right now with just two wires connected to the CPU.
A mechanical rotary encoder consist of switches that are opened and closed in a predetermined sequence. During the switch transitions noise is generated, typically lasting from 1 to 5 milliseconds; the switch is “bouncing”. The following photo shows a rotary encoder switching and captures the first millisecond after the swtich event. Notice that for approximate .7 milliseconds the switch is “bouncing”
In order to reliable determine the state or level of the switch, it has to be “de-bounced” either by adding hardware components to attenuate the noise or by waiting in the code sufficient time after the transition has occurred.
I'm probably more a hardware than a software jock and I'm quick to add components, but the easiest solution is to debounce the inputs in software, in maybe 30 years of writing embedded code I've never harmed a single resistor or capacitor when using a switch as an input.
For a beginner writing code though I can see that it would be much less confusing to just read a pin and have the hardware deal with the bouncing.
Interestingly the PEC11 encoder that I'm using (seems almost the same as the PEC12 linked to by CR) does not show any filtering in the datasheet even though it's rated bounce is 2.5x longer. (5mS vs 2mS).
It seems that even Bournes can't decide which is best