DIY USB MIDI controller MPC style - Compatible with Audio Adaptor Board

Status
Not open for further replies.

MickMad

Well-known member
Hey guys,

It's been a long time since my last post here on the Teensy forum, but this time I'm back with a new project!

It's a MIDI controller compatible with the Audio Adaptor Board and which can host up to 49 analog controls.

Basically, I used all the remaining pins on the Teensy + Audio Adaptor to implement a shared multiplexer bus which can currently host up to 3x 16 channels multiplexers on 8 pin connectors; there is a dedicate analog pin and inhibit pin for each MUX, while the control bits lines are shared between the MUXes. The 49th is actually just an analog pin hanging there :)

If you remove the audio adaptor compatibility, that is to say you use all the available pins on a Teensy, you could add up to 9 mutilplexers, that sums up to 145 full analog controls!

You can find the whole project development, from first cardboard prototype made a few months ago up to my exposition at the Maker Faire in Rome, at the following link:

http://hackaday.io/project/1601-DIY-USB-MIDI-controller-MPC-style

And here's a video of it being played by an amazing kid @ Maker Faire Rome 2014!


Cheers,

Mick
 
Hey there,

quick update:

Someone asked me if it was possible to create an 88 keys piano using this configuration and while thinking how to use both the Audio Adaptor Board and more than the currently available 48 analog controls I thought of a nice way to enable up to 128 controls using the same pins that are currently used to control 3 muxes:

the idea is to take the three inhibit pins to control an 8 channel mux, with its common pin as input connected to 5 V and its channels as output connected to the inhibit lines of up to 8 separate 16 channel muxes, while keeping the 4 control bits of the 16 channels muxes shared between them.

Also, all the 128 control will be used on the same analog pin, leaving three more analog pins free to use. This sums up to 131 useable analog controls, while fully retaining the audio adaptor board compatibility.

Neat, isn't it?? :D

Cheers,

Mick
 
Its a very neat project, nicely done.

That PCB looks huge (thus, expensive to have made, unless you etch it yourself). Do you find the 2mm acrylic top flexes at all?

I'm surprised that multiplexing so many analog inputs works so well when they are all continually sampled.
 
The sensor's PCB is 18 cm x 18 cm circa, it's pretty huge actually; I'm considering a modular version of the sensor's PCB which consists of a 2x2 matrix of pads, maybe with smaller pads; right now they are inscribed in a 1 inch diameter circle, and the distance between the center of the pads is 1.50 inches.

The 2 mm acrylic is flexing indeed, but mainly because the 4 acrylic supports that I had cut to hold the top in place are 2 mm shorter than they should for an issue with the design of the base; the 4 screws that hold the PCB on the base protrude 2 mm while their top should have been flushed with the PCB surface.

Here's a screenshot of the common out of the multiplexers (sampled at 5KHz rather than 32 because my oscilloscope is very low bandwidth but does its job) :

This is the FSRs output as seen by the analog pin of the Teensy with all sensors pressed down at kinda the same pressure (you can see that they don't perform all in the same way due to inconsistencies in the velostat layer)
oscilloscope 1.png

And here's the output of the extension board, with first button pressed, second not pressed, and the three potentiometers at different setttings.
oscilloscope 2.png

The sampling is pretty consistent; I can't wait to see how it will handle 128 inputs on the same analog pin :D I'm sure it will go great, given that I will optimize the sensors reading code.
 
Hello there guys;

I was just wondering if you could lend some help out there; I'm designing the new revision of this project, which will be composed of two main boards: one which will host the Teensy 3.x and up to 128 analog controls, and an expansion board that will add 128 more inputs. I'll also redesign the PCB pressure sensing resistors board, but that is going to be an add-on to the project.

In the design it will be easier for me to also use the pins under the Teensy, it will help me with the layout; the thing is not everyone will be fine with soldering a header to the underside pins and make his/her Teensy unusable with a breadboard; so, I'd like to know if I should keep a low profile and so keep using only the readily available pins or if it may be fine for potential users to sacrifice the breadboard usability of a Teensy to use it with this project?

Also, I want to add support for an RGB LED for each analog control, that is 256 addressable LEDs; will it be feasible using the OctoWS2811 library and WS2812 LEDs? Moreover, will it screw up with the Audio Library? If that's the case (it screws up) will it be feasible to use the RX1/TX1 lines to control a single line of 256 leds?

Thanks for your comments
 
I already saw that breakout board and it's pretty good, although I was thinking of making my own breakout embedded in the mainboard of my project; I was just thinking that soldering the extra pins on a Teensy 3.x just to use it with one project may be a deterrent for some people; I mean, I wouldn't care much about it since I will just plug the teensy on my motherboard and leave it there, while some people may still want to retrieve the teensy at one point to reuse it in other projects; on the other side, people that will be interested in such expansive project (256 controls, 256 leds) may want to build something durable and longlasting, so they may also not mind about permanently soldering that pins to the Teensy.

Anyway the fact that there is a readymade breakout board for it is a good starting point; if I decide to really go this way people that will use my project and one day would like to retrieve the Teensy can easily plug it into that breakout board and reuse it! Plus, I'd actually be doing them a favor by increasing the number of easy usable pins on the Teensy!

Other point: what about adding a pinout on the motherboard to breakout the remaining pins?

Point still open: usability of Audio Adaptor Board and OctoWS2811 library? Any news? Any substitute? library(I'd rather post this question on the audio thread though)
 
Other idea: what if I use a Serial in Parallel out 8 bit shift register to drive the multiplexers?

The lower nibble will drive the control lines of the input muxes, while the upper nibble will drive the control lines of the inhibit mux; I'd only have to use an 8 bit unsigned integer value to keep track what input is currently active, I'd increment that each time I read, and I'd write that value to the shift register using SPI. This will reduce the number of pins used to select inputs from 8 to 3-4 pins. This way I should not need at all the underside pins!

What do you think?
 
i don't know. i guess a typical thing you'd see in many audio devices is you have a second mcu handle the UI. you might use an atmega328 or the like and RX1/TX1 (?)
 
i don't know. i guess a typical thing you'd see in many audio devices is you have a second mcu handle the UI. you might use an atmega328 or the like and RX1/TX1 (?)

I actually thought about that for a moment, but then I realized that leveraging the multiplexing and the analog reading of 256 inputs using an interrupt at 256KHz (to keep the actual delay between reads for a single input at 1 ms) may not be a good idea; moreover it adds a cost overhead, a programming overhead (developing firmware to actually programming the atmega) and more space on the PCB, as well as slightly increase the level of difficulty of use for a beginner (in a diy/kit solution it may be difficult for an enduser to program its own ATMega because not everyone has a programmer); finally, I will still end up using kinda the same number of pins that I'd use with a shift-register->muxes configuration. In addition, it will be no fuss for the Teensy 3.x to handle such huge multiplexing while also handling USB MIDI stuff, at least; maybe it may become a problem using Audio functionality, but although full pin compatibility will remain it has not yet been tested, not even on my current working revision.
 
why, sure, it's not done because of pins but cpu and latency i guess.

as to the programmer -- if you can spare a pin as CS, i guess you could connect the atmega to the SPI port and use the teensy as programmer, which should be easy enough; the connection wouldn't be in use during normal operation, so that nothing interferes with reading out the SD card (assuming it'll be used)



I actually thought about that for a moment, but then I realized that leveraging the multiplexing and the analog reading of 256 inputs using an interrupt at 256KHz (to keep the actual delay between reads for a single input at 1 ms) may not be a good idea; moreover it adds a cost overhead, a programming overhead (developing firmware to actually programming the atmega) and more space on the PCB, as well as slightly increase the level of difficulty of use for a beginner (in a diy/kit solution it may be difficult for an enduser to program its own ATMega because not everyone has a programmer); finally, I will still end up using kinda the same number of pins that I'd use with a shift-register->muxes configuration. In addition, it will be no fuss for the Teensy 3.x to handle such huge multiplexing while also handling USB MIDI stuff, at least; maybe it may become a problem using Audio functionality, but although full pin compatibility will remain it has not yet been tested, not even on my current working revision.
 
why, sure, it's not done because of pins but cpu and latency i guess.

as to the programmer -- if you can spare a pin as CS, i guess you could connect the atmega to the SPI port and use the teensy as programmer, which should be easy enough; the connection wouldn't be in use during normal operation, so that nothing interferes with reading out the SD card (assuming it'll be used)

Well, since I'd like to keep the shift register design either way, I'd first produce one prototype and see how the Teensy performs, first with inputs only, then add the LEDs and finally the Audio adaptor board functionality (I might buy a Teensy 3.1 as well for this project); if that's too much, I might add a support MCU to take care of the inputs at least (I don't think the atmega will be able to handle both all those inputs and LEDs while communicating through serial), but again I feel like this will just end up in complicating the board design. We'll see.
 
Status
Not open for further replies.
Back
Top