I may be jumping into the deep end (never made a midi controller before) but I basically want to scratch build this .
In fact I want to go even bigger, with 15 faders, 30 no button rotary encoders, 5 push button (flat style) rotary encoders and 60 keys. Im planning on following this build guide , but essentially just making the fader wing part.
The issue is that with each encoder requiring 2-3 digital I/O pins, each fader requiring 1 analog pin, and the key matrix requiring 19 I/O pins, I've worked out that i need 109 total pins to make it all talk.
This number does fit perfectly within the 110 I/O pins that I could get with two Teensy 4.1s but I'm wondering how much complexity is added by using two separate controllers, or if there is a larger option that could be recommended to integrate this all onto one board?
This guy separated out all of the keys into a QMK teensy and all encoders/faders into a MIDI teensy. I also would like to know if this is necessary, or if it has any advantages over putting keys and faders onto the same board.
I think I kind of laid it out. I want to build a midi controller with 15 faders, 35 rotary encoders, and 60 keys. The links are just to a production model with a matching layout, and to a build guide where someone built a similar controller with more keys and fewer encoders/faders. He was able to get all keys on one teensy and all faders/encoders on another. My design calls for more I/O than his.
If you don't want to use more than one MCU you can always use GPIO Expanders. They are usually connectet to the MCU via I2C. I recently received a pair of models for a project and they do quite excellent.
And you can save some pins even from the Extender by using plain vanila 74HC595 shift registers for the output only pins.
Is there a limit to how much you can expand with GPIO expanders before overloading the primary MCU?
And what are the disadvantages of just using more than one MCU?
15 faders are likely 15 analog inputs, with or without filtering, scaling, etc.
60 keys could be as simple as a Nano scanning the keys, presenting a 'mother' with keypresses - but, can they be simultaneous/overlapping, or will they allways be sequential?
35 rotary encoders could be a huge challenge, if many can be rotated quickly at once; simple, if only one changes at a time; increasing complexity if there are 'subgroups' that could change at the same time. Details like the speed-of-change, fidelity, etc. will be needed. This element will likely be the most challenging to implement, depending on your exact needs.
I'm one of those who will not follow links elsewhere, preferring to see the OP of the thread do some thought processes to coalesce their project into a reasoned "here's what I want", so it's now up to you to define some of the details I've observed to be missing. So far, I see a project that might even be fit into a Mega, with some auxiliary devices, depending on your real needs.
The MIDI side of things I know nothing about, though.
Multiples of keys and faders will need to be operated at the same time.
The first 30 rotary encoders do not need to be rotated at the same time, but it would be a plus if I could rotate two at a time.
I want 5 push-button rotary encoders that would need to be rotated at the same time, but that could be a separate project altogether.
I've seen posts online where people have used as many as 16 GPIO expanders along with a complex structure of matrix controllers, motor controllers, pwm controllers, etc. all communicating over i2c to get this exact same set of inputs (Plus motorized faders and LEDs) to all work on a single teensy 4.1. (photo attatched. Note: this person is trying to replicate the exact same control surface that I am.)
Thats cool but I'm not trying to use LEDs or motors, so I don't need as much I/O as this guy. I'm wondering if it would be possible for me just to break this up into two sets of 55 I/O pins and run each set of 55 directly to its own teensy 4.1. Then my computer will just see two midi controllers.
I think @alto777 and @camsysca gave much of the facts, and gave some opinions, with wich I mostly agree. But there are not conclusions, as the project description is pretty precise in hardware to be connected (give or take a dozen or two...), but I've no idea of what the software controlling those I/O will be doing with the data received.
Starting with the term Overloading, of course you're not getting your MCU melted down (you know that), and of course you can have your MCU read as many pins or GPIO Expansion boards as you need, and act over motorized outputs, as many as you want...
Does the MCU have enough power to do all that at your required rate (frequency)?
Does the reading of such amount of I/Os leave you enough to process the data and do the actions required by the input changes? (there comes in your MIDI knowledge).
Is there enough processing power left to update on time the outputs, and how long it'll take to update those outputs?
Of course you can use as many MCUs as you want, but your original post stated:
So it was about I/O pins per MCU board forcing you to add boards to get 110 I/O pins.
My answer is still the same: you can solve the I/O pins quantity using GPIO Expanders. If the time and resources needed for reading and writting to those I/O ports can be done leaving enough processing time and resources for the main application... depends on your application.
Teensy 4.1 is a Cortex M7 at 600MHz, which is a ridiculous beefy CPU compared to your typical Arduino. I think you could hang quite a lot of IO expanders off that. It also has CAN, which could be used to create a network of devices if needed.
As I understand the processing on the MIDI side is minimal. I would try a small prototype and estimate the CPU usage to guesstimate how many expanders could be supported.
For your faders, a 74hc4067 16-channel analog multiplexer. 4 digital inputs control which analog signal is passed to the output which you can connect to a single Arduino analog input. Those 4 pins could be Arduino pins or I/O extender pins. Alternatively, you could add 4x 4-channel i2c ADC modules like ADS1115.
For your 60 buttons, arrange as an 8x8 matrix, which will require 16 pins. If multiple buttons can be pressed simultaneously, you need to add a small diode in series with each button. Those 16 pins could be Arduino pins or I/O extender pins. A suitable i2c I/O extender could be PCF8575 or SX1509. The latter has built-in matrix scanning, which could be useful.
35 rotary encoders is, as others have already said, a significantly challenging project. Ideally you would need either 35 or even 70 Arduino pins with interrupt function. Using I/O pins for this could be difficult because they are slower than Arduino pins which could result in movements being missed.
Yes, but I do not think you will be close to that limit with this project, even if a basic Arduino is used.
Each MCU needs different code and they probably need to communicate and coordinate between them. This makes the code much more difficult to write and debug.
If you can partition the project so that the MCU can operate independently and don't need to communicate/coordinate, that would make things significantly simpler and more likely to succeed. But it may take up several USB sockets. A USB hub may be needed.
It appears that only 8 of these can be connected to the same i2c bus, so you would also need to use an i2c multiplexer (like pca9865) to connect 35 of them.
This does not translate into the need for 60 inputs. You can use a scanning matrix to reduce that to an 8 by 8 matrix. so just 8 inputs and 8 outputs. That is just 16 pins.
It is seldom a good idea to use more than one processor in a project, but it is a popular "beginners" solution. They then come here asking how to do it, and we have to put them right.
I supposed the limitation would be related to the address space, so I checked the page, and it clearly states that: If you happen to need more than 8, it's possible to set the I2C address with a special address-change command that is saved to the onboard non-volatile EEPROM memory.
So your recomendation even takes away the need of the multiplexer, just a pre instalation command.
Wow! I really appreciate all the feedback and advice! @PaulRB
I definitely can partition, as far as I'm concerned I could even make this as 3 entirely separate midi controllers that share a housing. Then I'd just use LoopMidi to bring them together. At least this was my initial plan.
I'm seeing this view a lot. And as such I'm inclined to respect it.
This seems like the way to go. The teensy 4.1 has three i2c busses. Would I get better results spreading these out, or am I better off putting these all on one i2c bus?
There is no reason to use multiple buses, unless you use RTOS and read devices in parallel in different threads.
More important is to hook up least used RE on one PCF and the most used on another.
If you read the most used PCF you can update all 8 most used at once. It would allow to use a different frequency of polling them.
Better is to use interrupts and read the right PCF in one call (not scanning all 5 of them).
And use 400kHz i2C speed, is about 2.5x faster than 100kHz.
