Hi folks,
I am planning to build a massive reto-synth inspired midi controller with a whopping 176 rotary encoders (not potiometers) and 32 toggle switches, plus a few other bits and bobs.
I have been researching options for this for a while and come up with two general architectures:
Option 1
Distributed processing with Teensy Master and 3 ESP32s with multiplexer arrays to handle encoder inputs. Basically, each ESP would process 64 encoders and switches, and pass the information to the teensy over UART packages.
Option 2
A teensy with chains (three sets of 22 deep!) of step registers 74HC165 (DIP-16) to gather the digital inputs from the econders and switches and process in one heap.
The first option may provide a little more flexibility in pre-processing, and I think the ESP32s should handle 64 encoders and the switches sufficiently quickly, even though they are processed sequentially.
The second option seems to be more efficient, as all encoders and switches read at every cycle.
The design will benefit from the fact that it is only humanly possible to move two encoders or switches as a time, so we are not talking fast changing data here.
Does anyone have experience in creating massive pools of digital input devices? If so, what are your thoughts and tips of both or either of these two approaches?
1 Like
Option 1 depends on the type of encoder. An encoder that depends on the MCU counting pulses as it is moved will not work in a multiplexed system, as it relies on interrupts. If the encoder canāt inform the MCU that it needs attention, and has to wait for the MCU to swing by, then interrupts wonāt work.
If itās the type of encoder that calculates it position and reports that position when requested, then that would be OK because the multiplexing will likely be able to keep up with whatever the user can do (although you can be pretty sure the user will find a way to move more than two encoders at a time).
For option 2 I canāt see what the arrangement would be. You seem to be implying that the registers provide a means for the teensy to access 8 digital inputs of three bits each through each MCU port. But 3 bits is not enough for an encoder to report its setting.
1 Like
Man talk about targeted clickbait.
I absolutely need to see photos of this when itās done ya know?
Yeah actually. I just finished a project where I needed 20 servo motors all controlled via open sound control. To distribute the logic I used the I2C protocol.
i2c was great for me because it meant each individual device was responsible for fewer things, making it more responsive. Additionally, when it came time to debug, my master device had lotās of logging and it was really easy to find where the problem was.
This modular approach is most similar to your option 1 using UART.
I must say the multi-device style infrastructure had a pleasant, take it one step at a time, build process.
With that being saidā¦
Aesthetically Iām in love with your option 2.
I would consider trying to build some kind of bus to try and compartmentalize it.
Then I would use these 74HC125 tri state buffers to manage who own the bus at each point.
my two cents.
1 Like
Thank you for the diagram. It is very similar to my option 1. The teensy is going to be the master, since it has USB midi. I have what I need to prototype that up to 64 encoders (will start with a far smaller number)
Comments on option 2 are appeciated. I plan to prototype that an, it the clock speed it up to the task. Will definately keep it modular as you suggest.
As for the click baitā¦ this is my ābucket list projectā. Every five years or so I take on a new area to learn. Over covid, it was modular synths (virtual, with VCV and Cherry Audio Voltage.) That took me into the virtual retro synth worldā¦ but.. I really wanted my knobs to twist! I purchase the wonderful German Faderfox PC12, but it lacks the ability to quickly switch between synths and have all knobs remapped and on-target. So I looked at rotatary encoder devices and got the ElectraOne, which is excellent bit of kit, but still did not give me the olā school FEEL I wanted. I began design my ideal midi surface: one that can handle the naunces of the dual CS-80 (Cherry Audio CX-80 is a beautiful thing!), Elka or the Glorious Korg 3300. Hense the need for lots of encoders and switches. I intend to go ā80ās Dr Who Tardisā with the look of the controller. So I guess I also need to learn carpentry.
My plan it to take this project slowly. Starting with 8, then 20 encoders, then moving to 64, etc. Early iterations will be a cardboard frame. I have no idea what Iām doing, but Iām spending effort researching options, reaching out to others whoāve done synth or controller projects, etc.
So, yeah. Trying to keep this bedraggled brain busy and distracted.
1 Like
Nice one man.
Feels good.
Just letting you know that I believe UART is a device to device protocol.
Both Option 1 and Option 2 may both need a bus of some sort: something for multiple devices and or components to share and talk to the teensy. Iām not saying you canāt do that with UART, but some of the strengths of i2c and spi is that theyāre protocols that assume a bus.
You could make a UART bus if you were inclined.
I donāt think you can put pull-ups on the UART lines though so you might have to connect and disconnect between each transmission??? ā¦ uhhh not sure about that more research might be required before you commit.
Also seconding what @Jeff105671 said about multiplexers. I wouldnāt fancy having to micro manage the clock of my multiplexor whilst handling all of that traffic.
1 Like
I second the I2C suggestion! Fewer wires and the ability to have many encoders wired through the same input sounds like a helpful thing, considering the number of encoders you are planning on using.
SPI would also work and is usually faster in most cases, but in my experience, it can be a little more complicated than I2C to implement.
2 Likes
