Need some guidance for hooking up 54 inputs for a MIDI controller.

Status
Not open for further replies.

Aimbit

Member
I am trying to hook up 25 buttons and 29 potentiometers to build a midi controller. I am not sure which teensy board I need to accomplish this. I am under the impression that buttons are digital inputs and POTs are analogue. Can someone lead me in the right direction?

Additionally, the buttons are LED, is there a separate controller or something I need to light them?

thanks
 
No teensy has that many pins, as most of the analog inputs overlap with the digital pins, Without the analog inputs (potentiometers), you would need to use 50 out of the 51 digital pins on the Teensy 3.5 and 3.6 (you need one pin for the input and one pin for the LED). The Teensy 3.5 has 27 analog inputs (the 3.6 has 25), so even without the digital pins, you would not be able to hook up all of the analog pins. And note, 18 of those pins are on solder pads underneath the Teensy that may or may not test your soldering skills.

So you need to use extra controllers that each talk to the master Teensy. You could go the i2c route. You could add 4 MCP23017's that each one supports 16 digital pins for input and output. And you can get 7 ADS1115's to give you analog reads. But at 11 chips on the i2c bus, that is getting to the point where you need to start worrying about engineering the i2c bus. Or with a bit of programming (since the normal libraries only support one i2c bus), you could use all 3 i2c buses on the Teensy 3.5 or 4 i2c buses on the Teensy 3.6 and put 4 chips per i2c bus.

Instead it may be better to break the problem and use some Teensy LC's to support some number of digital inputs and digital outputs, as well as analog inputs. For example you could have each LC support 10 analog inputs and 13 digital inputs or outputs. Then have the LCs talk to the master Teensy about buttons pressed, and inputs. It likely will be somewhat of a challenge to program multiple chips instead of one. On instead of LC's, you could just use 2 Teensy 3.5's, with each 3.5 supporting 15 analog inputs and 25 digital pins. You would need to communicate between the two Teensys, with one being master and the other being slave.

I would start small and redefine the program for a smaller number of inputs and outputs that can be handled with 1 digital i2c board and 1 analog i2c board. Learn how to talk to the board, etc. Then grow it slowly.
 
No teensy has that many pins, as most of the analog inputs overlap with the digital pins, Without the analog inputs (potentiometers), you would need to use 50 out of the 51 digital pins on the Teensy 3.5 and 3.6 (you need one pin for the input and one pin for the LED). The Teensy 3.5 has 27 analog inputs (the 3.6 has 25), so even without the digital pins, you would not be able to hook up all of the analog pins. And note, 18 of those pins are on solder pads underneath the Teensy that may or may not test your soldering skills.

So you need to use extra controllers that each talk to the master Teensy. You could go the i2c route. You could add 4 MCP23017's that each one supports 16 digital pins for input and output. And you can get 7 ADS1115's to give you analog reads. But at 11 chips on the i2c bus, that is getting to the point where you need to start worrying about engineering the i2c bus. Or with a bit of programming (since the normal libraries only support one i2c bus), you could use all 3 i2c buses on the Teensy 3.5 or 4 i2c buses on the Teensy 3.6 and put 4 chips per i2c bus.

Instead it may be better to break the problem and use some Teensy LC's to support some number of digital inputs and digital outputs, as well as analog inputs. For example you could have each LC support 10 analog inputs and 13 digital inputs or outputs. Then have the LCs talk to the master Teensy about buttons pressed, and inputs. It likely will be somewhat of a challenge to program multiple chips instead of one. On instead of LC's, you could just use 2 Teensy 3.5's, with each 3.5 supporting 15 analog inputs and 25 digital pins. You would need to communicate between the two Teensys, with one being master and the other being slave.

I would start small and redefine the program for a smaller number of inputs and outputs that can be handled with 1 digital i2c board and 1 analog i2c board. Learn how to talk to the board, etc. Then grow it slowly.

Now if you could direct me to the place I could read to understand what you just said, that'd be great :)
 
This may be overly obvious, but please try to avoid a mistake many others have made with large MIDI controller projects.... before you wire up tons of hardware, start simple with just one button and one pot to learn how things work. Even though you'll ultimately need to use mux chips like 74HCT4051 or I/O expanders or multiple Teensy boards with serial communication, don't try to do all that on your first attempt. Just run the examples from File > Examples > Teensy > USB_MIDI with the minimum possible hardware as a first step. Obvious as this sounds, we've seen plenty of DJs and others wishing to build a huge MIDI controller go pretty far down a wrong path, where it's painful and expensive to later change course, all because they skipped these first steps to gain some experience with how things really work. Don't make that mistake. Do some simple tests first with the examples. Try the ResponsiveAnalogRead library with one or two pots. It's time well spent.
 
This may be overly obvious, but please try to avoid a mistake many others have made with large MIDI controller projects.... before you wire up tons of hardware, start simple with just one button and one pot to learn how things work. Even though you'll ultimately need to use mux chips like 74HCT4051 or I/O expanders or multiple Teensy boards with serial communication, don't try to do all that on your first attempt. Just run the examples from File > Examples > Teensy > USB_MIDI with the minimum possible hardware as a first step. Obvious as this sounds, we've seen plenty of DJs and others wishing to build a huge MIDI controller go pretty far down a wrong path, where it's painful and expensive to later change course, all because they skipped these first steps to gain some experience with how things really work. Don't make that mistake. Do some simple tests first with the examples. Try the ResponsiveAnalogRead library with one or two pots. It's time well spent.

Hi Paul,

I actually have breadboarded a controller with an Arduino and it appears that my only limitation right now is number of inputs.

If I understand correctly, a multiplexer will allow me to use 1 analog input as, say, 8 inputs? And it hooks up via DIGITAL pins, but works with ANALOG Pots?
 
Last edited:
Hi Paul,

I actually have breadboarded a controller with an Arduino and it appears that my only limitation right now is number of inputs.

If I understand correctly, a multiplexer will allow me to use 1 analog input as, say, 8 inputs? And it hooks up via DIGITAL pins, but works with ANALOG Pots?

That is for the most part correct, it is controlled via digital pins to select 1 of 8 positions that can then be read or output to from either a digital pin or an analog pin. For simplicity’s sake, multiplexers work great for controllers, the most I’ve done is 96 I/Os with a total of 12 multiplexers and it works great with one Teensy 3.6 it likely would work great with a smaller Teensy as well, but I just had that one on hand so I used it. I used 3 of those multiplexers to control my leds and while not really recommended to do so it will work great provided your program runs fast enough to trick your eyes into thinking all are on at the same time.
 
With that number of controls, you could also consider using a HMI touch screen, i.e. from Nextion or 4d Systems, which connect via a single hardware serial port and which would not only allow you tou virtualize even a bigger number of controls, but also to organize these logically in different screen pages, so that the user would not be overwhelmed by this huge number of (virtual or physical) controls at the same time, but he would always select a screen with the logic group of controllers he needs and then make his settings before switching to the next screen page.
 
With that number of controls, you could also consider using a HMI touch screen, i.e. from Nextion or 4d Systems, which connect via a single hardware serial port and which would not only allow you tou virtualize even a bigger number of controls, but also to organize these logically in different screen pages, so that the user would not be overwhelmed by this huge number of (virtual or physical) controls at the same time, but he would always select a screen with the logic group of controllers he needs and then make his settings before switching to the next screen page.

Well, the design is going to mimic a virtual synth instrument. The plan is to make a physical version of the front panel so I can control the VST in a 1:1 fashion. Although future projects using a touchscreen sound interesting :) I think I need to get a little better at electronics first before I do that.

thanks
 
That is for the most part correct, it is controlled via digital pins to select 1 of 8 positions that can then be read or output to from either a digital pin or an analog pin. For simplicity’s sake, multiplexers work great for controllers, the most I’ve done is 96 I/Os with a total of 12 multiplexers and it works great with one Teensy 3.6 it likely would work great with a smaller Teensy as well, but I just had that one on hand so I used it. I used 3 of those multiplexers to control my leds and while not really recommended to do so it will work great provided your program runs fast enough to trick your eyes into thinking all are on at the same time.

So what is the deal with LED's? My primary use for them will be to indicate either On or Off. Nothing flashing or anything like that. Is the issue with MUX and LEDs? Should I use a separate board for just LED's?
 
So what is the deal with LED's? My primary use for them will be to indicate either On or Off. Nothing flashing or anything like that. Is the issue with MUX and LEDs? Should I use a separate board for just LED's?

If you use a mux for LEDs the only way to have every LED “on” is to flash between them many times per second since with a mux only one can be on at any time, but if they flash fast enough you can’t tell. Just like on old CRT screens only one pixel is ever on at one time, but your eyes think the whole thing is on.
 
If you use a mux for LEDs the only way to have every LED “on” is to flash between them many times per second since with a mux only one can be on at any time, but if they flash fast enough you can’t tell. Just like on old CRT screens only one pixel is ever on at one time, but your eyes think the whole thing is on.

Gotcha. So ideally I'd want them running on a dedicated board?

As far as POT's and MUX go.. will there be diminished accuracy due to this polling? Would this also mean you can't turn 2 knobs at the same time on the same mux board? Not likely an issue for what I'm doing, but I would just like to know :)
 
Gotcha. So ideally I'd want them running on a dedicated board?

As far as POT's and MUX go.. will there be diminished accuracy due to this polling? Would this also mean you can't turn 2 knobs at the same time on the same mux board? Not likely an issue for what I'm doing, but I would just like to know :)

I haven’t noticed any decrease in accuracy, but you can actually turn all 8 knobs on the mux board at the same time with no noticeable lag as long as the program loops fast enough. When you use muxs you basically want to keep the code size to a minimum so you can spend as much time reading the muxs as possible which is great for controllers since you are unlikely to do much else. And if you want to use encoders with muxs you can as well, the most I’ve used is 24 encoders (48 pins) which was half of the 96 I/Os I had available from the muxs I used in the controller and it didn’t miss any steps that I could tell while I tried to turn as many of them as I could.
 
I haven’t noticed any decrease in accuracy, but you can actually turn all 8 knobs on the mux board at the same time with no noticeable lag as long as the program loops fast enough. When you use muxs you basically want to keep the code size to a minimum so you can spend as much time reading the muxs as possible which is great for controllers since you are unlikely to do much else. And if you want to use encoders with muxs you can as well, the most I’ve used is 24 encoders (48 pins) which was half of the 96 I/Os I had available from the muxs I used in the controller and it didn’t miss any steps that I could tell while I tried to turn as many of them as I could.

thats awesome. thanks so much for your input :)
 
I haven’t noticed any decrease in accuracy, but you can actually turn all 8 knobs on the mux board at the same time with no noticeable lag as long as the program loops fast enough. When you use muxs you basically want to keep the code size to a minimum so you can spend as much time reading the muxs as possible which is great for controllers since you are unlikely to do much else. And if you want to use encoders with muxs you can as well, the most I’ve used is 24 encoders (48 pins) which was half of the 96 I/Os I had available from the muxs I used in the controller and it didn’t miss any steps that I could tell while I tried to turn as many of them as I could.

Do I need extra software to have Teensy send midi through USB? I know that with my Arduino I need a virtual midi port and then another program to read the midi signals... it seems excessive since with a normal USB midi controller you just plug and go... is there a difference?
 
Teensy has native USB support for a variety of devices, usbMISI happens to be one of them so no additional software is needed as long as your OS has a general MIDI driver which most tend to have nowadays. Being that it is native it will also work on mobile device if you so desire to use it with iOS or Android.
 
Status
Not open for further replies.
Back
Top