You can put rotary encoders in a keyboard matrix!

[Snipeye]

I've managed 32, in the pictures below I built a board that does 30 - you need about 2K+ scans/second to avoid missing a transition, but that's not too hard to achieve.

Additionally, since encoders have the "common" pin between A and B, you need 2 matrix slots in the same row (if diodes are oriented col2row) or the same or the same column (if diodes are oriented row2col).

Aside from that, it's pretty straightforward.

 IMG_7584_1080.mp4 (29495 kB - downloaded 13 times.)





I have a PR to QMK to show how it's done, visible at https://github.com/qmk/qmk_firmware/pull/23700 if you care.

[fpazos]

Very interesting, seems really useful for custom midi controllers.

[Findecanor]

you need about 2K+ scans/second to avoid missing a transition, but that's not too hard to achieve.

That's interesting. How do you debounce them?

Do you report a step on the next change and suppress only the opposite turning direction for the bounce period?
Or do you not need to?

[Snipeye]

Very interesting, seems really useful for custom midi controllers.

Yeah, that's what the 32-encoder board I designed (for a client) does - a synth of some sort; I'll ask him if he's OK if I post pictures.  Various knobs to change variables like frequency, wave type (sawtooth, etc)... I don't know what else, but he was asking for as many knobs as he could possibly get, haha.

As far as this board... it's not useful except to prove that the encoders work in the matrix.  IDK if you watched the video (first attachment), but I've set it up so that turns on alphabetic keys shift their mapping (a -> b, b -> c on clockwise turns, and backward on counterclockwise).  Really don't know what else to do with it, lol - 30 volume controls?  Somebody suggested "30 volume controls but each one only controls 3.3% of the total volume" or "30-player pong somehow"...

[Snipeye]

you need about 2K+ scans/second to avoid missing a transition, but that's not too hard to achieve.

That's interesting. How do you debounce them?

Do you report a step on the next change and suppress only the opposite turning direction for the bounce period?
Or do you not need to?

The traditional method for debouncing encoders is to pass the raw outputs through a state machine (I didn't look closely, but I think it's described right in the stackexchange post https://electronics.stackexchange.com/questions/360637/quadrature-encoder-most-efficient-software-implementation).  QMK debounces individual keys in the matrix, and those debounced values are currently getting handled by the state machine so it's sort of double-debounced, which is providing some less-than-graceful results (the default key debouncing is too aggressive/not a good fit for an encoder).

I've written (for the client I mentioned in my previous post, with 32 encoders) a bitfield-state machine that handles all 32 encoders in parallel by performing bitwise operations on uint32_t variables that worked really well - I plan on submitting another PR to QMK to implement this method since it debounces all encoders at once (instead of running a loop that debounces them all individually).