Drawbars MIDI Controller planning questions

Status
Not open for further replies.

garubi

Well-known member
Hallo,
first time here, I’m Stefano from Italy. :D

I’m planning the construction of a MIDI Controller and I need some help to decide if a Teensy LC is enough for my needs or if I need the Tennsy 3.2.
..and while I’m here… It would be nice to ear your comments on the whole projects feasibility and critical points.

While I’m certainly not an expert on electronics, I already built some Midi Controllers, but never using Teensy or Arduino, I always used “Brain” from http://lividinstruments.com/products/builder/
(my “best” project is this Hammond Clone Controller).
My everyday job is to program in PHP and Javascript so, even if this languages are not even near the complexity of the Teensy programming, I have a good understanding of programming etc

I’m planning the build of a “Drawbars” MIDI Controller with approximately
  • 9 faders (slider pot)
  • 8 buttons
  • 2 pot

I’ll then use it to control Drawbars and to switch on/off the other elements of digital Hammond Clone either via USB or via MIDI DIN IN/OUT

The controller has to send Program Change, Control Change, Note ON/OFF and short messages of SystemExclusive (yes, most Roland Keyboards need SysEx to control theyr "drawbars implementation" either via USB2MIDI and classic MIDI DIN

It should run either connected to a computer (USB2MIDI) or as a standalone unit (MIDI DIN) connected to Keyboards or synth.

I’ve read a lot about Teensy, it’s MIDI capaabilities, etc… but even so I have some (err...really a lot of) questions… here the first two:
1- Do you think that Teensy LC is ok for such a project? or I need a Tennsy 3.2?
2- I read a lot about the USB2MIDI capabilities of Teensy, but on the “classic” MIDI DIN side I’m not sure that there are libraries and support as well. Can you confirm / expand on this?

Thank you for your attention (and for the help that I'm sure I'll get)

Stefano
 
The MIDI DIN you are asking about is done with this library: https://www.pjrc.com/teensy/td_libs_MIDI.html

It is very easy to use and can work alongside the usb MIDI.

As far as the LC vs the 3.2, it looks to me like you'd be fine with the LC based on the pin count, but you are using most of the analog inputs. However, I'm not sure about the difference in the serial ports on the LC vs the 3.2 and if it's a problem or not. My first thought is that it's ok because I have seen other midi controllers made with the LC. Hopefully others will chime in on that point.
 
I reckon you would probably be alright with the LC, but you should buy an LC and a 3.2 .... having a spare teensy is a must, in my books, in case of accident. And that way you can test the difference in speed if there is any.....

Also, you would be surprised at how fast you can fill up the LC memory! But for a midi controller I doubt that would be a problem, but, well, it depends on your application.... EEprom is also limited on the LC, so it depends on how much 'settings' / presets you are going to store .... again shouldn't be a problem .....

but you should just buy one of each, anyway, to have a backup, in my opinion.
 
LC is more than enough.

MIDI and usbMIDI are both very capable on their own but don't play nice when you try to shuttle traffic between them (because of internal differences that make passing all MIDI types difficult).

As long as your device is only sending it should not be a problem (no Merge and Thru functions).

You just have to call two different send functions for each message type... one sends up the USB and the other through tx to your DIN
 
Thank you to all for your frendly answers!

The MIDI DIN you are asking about is done with this library: https://www.pjrc.com/teensy/td_libs_MIDI.html

It is very easy to use and can work alongside the usb MIDI.
Wonderful, thank you!

I reckon you would probably be alright with the LC, but you should buy an LC and a 3.2 .... having a spare teensy is a must, in my books, in case of accident. And that way you can test the difference in speed if there is any.....

EEprom is also limited on the LC, so it depends on how much 'settings' / presets you are going to store
Yes, it's really my plan: to buy one of each... I have other projects in my mind... ;)
For the settings in EEPROM I'll see in the future... for the first iterations I'll don't use settings at all...


MIDI and usbMIDI are both very capable on their own but don't play nice when you try to shuttle traffic between them (because of internal differences that make passing all MIDI types difficult).

As long as your device is only sending it should not be a problem (no Merge and Thru functions).
Ah I see... thank you for the alert...
I don't plan any Merge between USB and "DIN".
I'm thinking of making a software merge between In and OUT on the DIN part, would it be a problem?

Stefano
 
I’m planning the build of a “Drawbars” MIDI Controller with approximately
  • 9 faders (slider pot)
  • 8 buttons
  • 2 pot

Ops... I forgot to mention I need to have a bunch of LED... could be 8 or 10...
If I well understand LED and buttons are connected to Digital pins so to remain in the TeensyLC limit I can have max 27 of them (without using MUX etc).
Is it right?

Stefano
 
Yes there are 27 io pins. You need 11 of 13 analog capable for pots and 8 digital for switches which would leave you with 8.

Only 10 analog pins are available from the breadboard friendly edges so you will need to grab pin 26 from the end or one from the inner row behind 21/22.

I'd consider a mux for the 8 buttons to free up enough accessible pins for LEDS or anything else you may want to add. Or mux 8 pots and then you could use only the L/R edges (breadboard friendly).

Or you could go with 3.2 and deal with io pads off the back but avoid the mux.
 
Or maybe it makes more sense to look at an LED driver IC via I2C or similar

I don't know much about this.... anyone else?
 
For the LEDs, you could use ws2812b (neopixels), which on the LC there is a convenient port (A3) that is mapped to VIN and brought out the back. You would lose one analog port, but you can use both of the internal analog ports (A10/A11) or use the back analog port (which is also the DAC) A12.

On the Teensy 3.2, FrankB's Connectorboard 3 is perhaps the easiest to solder to bring out the bottom pins: https://pcbs.io/user/FrankB. Besides the 3 analog input pins mentioned for the LC, there are 8 additional analog input pins on the bottom of the Teensy 3.2, and 10 digital input/output pins (2 of the analog input pins cannot be used for digital input/output).

Or if you can wait until November or December, the Teensy 3.5/3.6 should be available via retail sales after the kickstarter rewards are delivered. The Teensy 3.5/3.6 have 21 analog input pins that are easily accessible via breadboarding and 39 digital input/output pins (most of the digital input/output pins overlap).

Moving the LEDs and/or analog inputs to i2c devices is another possibility.
  • You can use ADS1115/ADS1015 boards to bring out 4 analog inputs, and you can attach up to 16 ADS1115/ADS1015 boards for a total of 16 analog inputs.
  • You can use MCP23017's to provide 16 digital input/outputs, and you have up to 8 MCP23017's on an i2c bus for up to 128 digital input/outputs.
  • If you need to use PWM to run servos and/or vary the light intensity, you can add i2c or spi devices to run the PWM devices (Adafruit's PCA9685 device can do 16 LEDs/servos for instance, and you can wire up to 62 of the boards on the i2c bus for 992 outputs, though I suspect other things will limit you if you try to put that many i2c devices on a bus).

For i2c, you need to add pull-up resistors (typically 2.2K, but it can vary depending on how complex your i2c bus is) between each of the i2c SDA/SCL pins and 3.3v. Note, by default, you would lose 2 of the analog input pins (A4/A5) to support i2c, but given you can move a lot of the inputs/outputs to i2c, it may be worth it).
 
Thank you for your further clarification.
What about making a diode matrix for the buttons to reduce the number of pin used? Or a led matrix?
Does this solution could help?

The Mux solution looks OK to me, and in the end also using a Teensy 3.2 will not be a problem... but since for me each new project is a way to learn new things... well I'm still here with those new questions ;-)
 
If you can wait until November or December, the Teensy 3.5/3.6 should be available via retail sales...

Running T3.5 at 120 MHz for a MIDI controller is like using a flame thrower to light a smoke... but it does offer lots of pins.

On pixel control... if you don't want fancy neopixels there are I2C and serial chips that drive plain LEDs... (serial data e.g. http://www.ti.com/lit/ds/symlink/tlc5917.pdf ) but then you need to mount and wire it somehow...

(The pinout of the example is simple and I don't think you need additional parts except one resistor so you could 'dead bug' it with wires directly soldered to the pins of the DIP chip.)

If you stick to no more than 8 LEDs you can still use an LC without any support chips but you'll have to access every data pin and not just the easy edges...

@anyone... is there any problem powering 8-10 LEDs directly?
 
Thanks to all your suggestions and clarifications. I took some more time to study the links you all provided.
At the same time I revised the plan for the controller.

I think that I'll can go with just 9 faders, dropping the other 2 pots.
Still I'm not sure if I can go with less than 9 buttons.
For sure I'll need more LEDs: I think between 14 an 16. They don't have to do anything fancy, just show the on/off status of the buttons. Just for 1 of the buttons there will be 6 led associated that at each press will rotate (1st press 1st led on, 2nd press 2nd led on...) to show 1 of 6 option selected.

All that said, I think I'll use I2C for the LEDs and the remaining free pins to connect directly buttons and faders, keeping in mind that I have to reserve pin 0 and 1 for the MIDI din (Uart).

I hope to have some free time in the weekend to do some more planning and verify if the controls will be enough for my needs.
In the meantime any your idea is welcome!
 
...[The LEDs] don't have to do anything fancy, just show the on/off status of the buttons. Just for 1 of the buttons there will be 6 led associated that at each press will rotate (1st press 1st led on, 2nd press 2nd led on...) to show 1 of 6 option selected.

If the buttons are acting as state toggles then why not use non-momentary switches and power the indicators directly thru the switches? (DPST with LED/resistor on one side and digital-pin on the other?)

There should be a way to manage the six mode-status LEDs with a shift register and a trigger pin.... I can't figure how to get the 1 into the first bit without wasting a pin output to configure it.

So maybe two pins where one sets 1 on first mode select and the other triggers the shift (I had though a register output could close the register into a circle but I can't figure how to prime it at startup.)
 
If the buttons are acting as state toggles then why not use non-momentary switches and power the indicators directly thru the switches? (DPST with LED/resistor on one side and digital-pin on the other?)
Yes it would be very easy and stright-forward, but I'm planning to use each button for more than one function (using one of them like a SHIFT/ALTERNATE key) so I need them act as momentary and using the LEDS to show the actual state. I'm planning to manage the "2 state/alternate state" in the firmware...
Your suggestion is anyway very tempting: easy and straight to the point... I could use it for the first iteration of the controller, less things to cope with: easy learning path...

There should be a way to manage the six mode-status LEDs with a shift register and a trigger pin.... I can't figure how to get the 1 into the first bit without wasting a pin output to configure it.

So maybe two pins where one sets 1 on first mode select and the other triggers the shift (I had though a register output could close the register into a circle but I can't figure how to prime it at startup.)
:eek: I barely understood what you wrote, my electronic knowledge is very limited... but thank you for the suggestion, because I used some hours of the sunday reading around about shift registers etc: learned a lot!

For the "rotation" between the 6 led I was thinking to manage it in firmware: at each press of the button a counter could be increased and when it reach 6 it will be reset to 0.

In general I would let the firmware doing a "lot of things", bet maybe I'm wrong... I think this is because I'm coming from a "software world" ;-) so really thank you for your help: It let me know a new world ;-)

Stefano
 
Last edited:
Re shift register suggestion.... I was kinda hoping someone would chime in on the best way to get a mini LED light chaser to advance on a trigger. I have minimal electronics experience too.

But this is what I was thinking....

Since a shift register moves it's input value over one spot with each cycle, if you start HIGH and then leave it LOW thru the next several cycles the 'on' bit will move thru the outputs driving a new LED each time a trigger is received... so you would set the input HIGH during the 1st pass of your mode loop and LOW in the others and trigger the shift on each.

I complicated things by noting that if you were to connect the input from the last used output it would make a loop for the one HIGH to cycle thru without having to set the input via code.... except I can't figure how you could get it started without using a second pin anyway.

FYI - you would need an 'unlatched' shift register (one that doesn't buffer the outputs until explicitly released).

On hard wiring LEDs to switches... I think you can use single-poll switches with the pin and the LED both on the same contact. But if you need to replace them with momentary switches later it's probably worth figuring out an LED controller now.
 
...if you need to replace [toggle switches] with momentary switches later it's probably worth figuring out an LED controller now.
...and once you do there's no point to a separate solution like a shift-register for the mode indicator... and if you ever add storing settings from EEPROM or selecting mode with sysex support you don't want to have to worry about setting the indicator by counting pulses.

I just thought there should be an easy way to control those six LEDs with one or two pins if that alone solved your pin shortage.


EDIT - It's called an Overbeck, or Ring Counter and it may be easier to set the HIGH bit by connecting flip-flops together from a chip like the 74HC174 but you still need to use a pin during start-up to 'reset'
Not to say I think you should :)
http://electronics-course.com/ring-counter
 
Last edited:
...and once you do there's no point to a separate solution like a shift-register for the mode indicator... and if you ever add storing settings from EEPROM or selecting mode with sysex support you don't want to have to worry about setting the indicator by counting pulses.

I just thought there should be an easy way to control those six LEDs with one or two pins if that alone solved your pin shortage.


EDIT - It's called an Overbeck, or Ring Counter and it may be easier to set the HIGH bit by connecting flip-flops together from a chip like the 74HC174 but you still need to use a pin during start-up to 'reset'
Not to say I think you should :)
http://electronics-course.com/ring-counter

:)
well, in any way I learned a lot !!

I decided to go with the pushbuttons wired directly to 8 PINs and LEds driven via I2C.
Now if someone could suggest me 2 or 3 different chip for drive the LEDs with I2c it would be great :confused: (I say 2 or 3 differnt models because I'm not sure I can find them here in Italy so I would like to have some choice ...)
 
Sorry for the late reply!
I collected all your suggestions and I tried to draw the schematic of the whole controller, adding the MIDI IN and OUT interface too.

If someone of has some free time to look at it and confirm it's ok or alert me of big errors it would be great. :)

I have not added any capacitor on the POT analog input but if I'll see to much noise I think I'll add. Done it on previous projects and it always helped.
Also, I connected the POT to AREF, is it ok or they have to be connected simply to 3.3V? EDIT: Answer FOUND down the thread!!! IT's wrong to connect the pots to AREF, they are to be connected to 3.3V. I'll attach a new updated and corrected schematic for future reference


Thank you for your help!!

abbozzo3_schem.jpg
EDIT: Attention. this schematic is the correc one. Before I attached one where I was wrongly connecting AREF
 
Last edited:
Looks like about 110 mA for the LEDs if all on...

The MIDI interface looks OK (Paul's recommendation for R values with 3.3 volt Teensy)

A cursory look at the MCP23017 connections; everything seems OK

I2C clock and data on default pins (I don't know the correct pull ups for those but I assume you do)

The pots and switches are good.

Nice.. looks good so far. Will be interesting to see your hardware.

Just curious... will you have detents on your drawbars/faders?
I don't know if that's still a thing but I believe some organs did as I recall playing with a home-style Hammond organ from '50s or '60s and my recollection is detent settings to call up the 'recipes' from a sounds book.

BTW - You got me wondering about the merits of SPI vs I2C; found an interesting reference:
http://www.byteparadigm.com/applicat...spi-protocols/
 
That's the best Fritzing schematic I've ever seen. Folks who use Eagle by just plopping down parts in random locations and connecting everything with short using with names could learn a thing or two from this. ;)
 
That's the best Fritzing schematic I've ever seen. Folks who use Eagle by just plopping down parts in random locations and connecting everything with short using with names could learn a thing or two from this. ;)

😀😀
Well, Thank you... I lost some precious working hours... so please don't tell it to my clients that are waiting for their website to go online 😉
 
Why did you? Did you read it anywhere? What difference would it make? I'd love to hear opinions about this!

Well, I think I read some reference that I can't find anymore... or it's just my mis-interpretation of what A(nalog)REF(erence) is.

Now re-reading the Analog Input How To I'm pretty sure that I'm wrong and have to connect directly to 3.3V

I hope someone chime in with a definitive answer :rolleyes:
 
Status
Not open for further replies.
Back
Top