Teensy, MIDI and motorized faders

Status
Not open for further replies.

Jazz

Member
I would like to use a Teensy 3.2 (or 3.5 if necessary) for a few audio/MIDI related projects and am wondering if some ideas are feasible/realistic.
The most ambitious idea would be a 2-way DAW Controller that would feature
- 18 motorized faders (16+2)
- about 60 rotary encoders with all of them having 15 LEDs arranged in a ring around them (for position feedback)
-about 100-120 pushbuttons
-possibly a display (could be 16x2, 20x4 or maybe a TFT)


I was thinking of using shift registers for the LED Rings, for the sake of simplicity let's assume 2 595s per LED Ring, giving a total of 120 (60*2) bytes for a complete update.
Buttons would be multiplexed .
I would like the motorized faders to be PWM'd , if possible through ShiftPWM and if at all possible, would like their potentiometer data to be read as 13 bit analog readings, for best precision and since mackie control-compatible devices send motorized fader MIDI data as a 13 bit pitch bend CC. These faders also need 2 touch pins on the teensy, I am assuming these can be multiplexed as well?

My main questions about this idea are if it's technically possible at all, but also how the latency would look like on such a system. I would like the internal latency to be under 5ms if at all possible, most critical are 2 way communication between the faders and the usb host, as well as sending rotary encoder input from the device. I don't mind going over that for things such as button input, updating LED rings as long as it's still reasonable, say under 20ms.

Thanks for reading and best regards!
 
Wow, that's a pretty incredible amount of I/O.

Long before you'll hit hard technical limits, there are many practical limits of what can be reasonably built and debugged. Many people have tried going down a path using massive numbers of shift registers and highly multiplexed I/O signals. In theory it's possible. In practice, it's almost impossible to manage and troubleshoot.

I would highly recommend you design this in a modular way. This may cost more in electronic parts and especially in connectors. But extra cost will be worthwhile the first time something goes wrong and you can easily unplug sections and (hopefully easily) troubleshoot them. Many, many people have built huge MIDI controller projects and focused on the cost of electronic parts, only to later discover the cost of construction materials, wires, connectors adds up quickly, especially if you use good quality stuff.

About your original question, yes there are some technical issues...

Achieving 13 bit analog signal quality is hard work even under good circumstances. Varying power delivery to 18 motors and 900 LEDs, and hundreds of multiplexed digital signals rapidly switching on lengthy wires sounds like pretty much the opposite of an ideal environment for low noise analog measurement. You might need dedicated power just for the analog stuff, and careful attention to grounding. ResponsiveAnalogRead can help you clean things up a bit. Even then, I'd be pretty amazed if anyone could achieve the full 13 bits in this environment.

Rotary encoders are tough to do with multiplexing. Generally each wants direct connection to 2 interrupt pins. No Teensy has 120 pins, so for 60 encoders you're automatically looking at multiple boards. Connecting them by serial at a decent baud rate should allow you to still pretty easily meet the 5ms goal.

ShiftPWM is definitely not going to help you with latency. It hogs a ton of CPU time to keep rapidly pumping out data to bit-band the PWM waveforms. You almost certainly should use PWM capable I/O expanders like PCA9685 if you want to control the LEDs with PWM. This keeps the digital communication to only the moments you need changes, and it keeps the rapid PWM switching localized at the LEDs. Both of these will help with the analog issues - and you're going to need this and every other advantage you can get to have any hope of 13 bits.

To keep latency under control, you're probably also going to want to dedicate a processor to the display. Then you can send a message by serial and let the serial interrupt take care of getting the message sent, while your code keeps up the scanning of so much I/O (or the rapid response to incoming serial messages from the other modules...) Almost all displays tend to take time to update, so if your latency goal is critical you really want to offload that task to another processor. The serial ports are the best way to do this. While I2C and SPI offer other benefits, the way the code is usually done will make achieving your latency goal harder.

If you do build all of this, or even a fraction of it, please take photos!!!
 
Thanks for taking the time to write that detailed and helpful reply.
Just a quick clarification , I would only need the PWMs on the motors (2 per fader, so 36 at most) , although now that you mention it, it could be interesting to dim "partially filled" LEDs (so as a simplified example, if I had 2 LEDs and the value to display was 25/100 , the first LED would light up at 50% brightness).
Also, quick follow-up question to the analog read resolution thing; this is probably gonna be a tough question to answer, but how good are my chances to squeeze out 11 or 12 bit resolution ? Every bit of precision helps (pun intended ... sorry ).

I have very little practical experience working with electronics and I will definitely start out with a less complex idea (something like 1-2 motor faders, 10 rotary encoders, 20-30 buttons). So far I did some isolated testing of (or playing around with) encoders with LED rings and the faders , which seemed to work well enough - although I imagine, as you mentioned, an actual project won't be quite as simple as that.
Either way, as soon as I have something that works, I'll be sure to post some pictures, some code and hopefully a short writeup on some of the code.


Thanks again and all the best!
 
You might have a look at my motorfader panel project. It's intended as a general purpose I2C controlled panel for use in large and or complex projects. I think it's safe to say that, at least for the reading, the resolution is 10bit. I figured i'd save myself a lot of trouble by just connecting everything to it's own teensy pin. Like Paul says, the cost of the hardware components (like motorfaders) quickly exceeds the cost of an extra teensy (3.6).

Kind regards,

Gerrit
 
Hey Gerrit, I actually saw that video on youtube before - good to know there's a thread accompanying it. Your project looks (and seems to work) amazing(ly), very professional. I'll be sure to study it more and take some inspiration from your setup&code.
Did you use the cheaper ALPS 100mm (with the motor sticking out from the bottom so to speak) or the more expensive ones with black casing / higher life expectancy? Also, being from Europe myself (Austria), where did you source them? I got mine from german supplier reichelt at 20€ a piece, but since these are the most expensive components for the project, I'd be curious if you found a better price somewhere.
Best regards!
 
You also have the option of using chainable port expanders on I2C or SPI. such as the MCP23S17 chip which is 16 bit and can either be used via polling or interrupts. This chip can have 8 addressable chips in a chain, with each chip having two registers of 8 bits.
 
Hey Gerrit, I actually saw that video on youtube before - good to know there's a thread accompanying it. Your project looks (and seems to work) amazing(ly), very professional. I'll be sure to study it more and take some inspiration from your setup&code.
Did you use the cheaper ALPS 100mm (with the motor sticking out from the bottom so to speak) or the more expensive ones with black casing / higher life expectancy? Also, being from Europe myself (Austria), where did you source them? I got mine from german supplier reichelt at 20€ a piece, but since these are the most expensive components for the project, I'd be curious if you found a better price somewhere.
Best regards!

Thanks :)
I got the faders from Conrad (€23,- incl VAT), these are the less expensive ones. You could use Behringer faders, the MFT100 are €82,- for 5 pieces at Thomann.de, no idea if they are any good.

How do you intend to use the controller, to control hardware or software? Just midi? Beware that if you're thinking of using the Mackie control protocol that there are serious limitation to this protocol (i.e. it sucks). I'm also working on a DAW controller using the Mackie control protocol and it takes some effort to work around the shortcomings of the protocol.

Kind regards,

Gerrit
 
Re resolution... 12 bits are feasible with sufficient smoothing/hysteresis methods.

Fader levels are very low frequency signals so jittery readings can be filtered very aggressively to obtain a fairly stable signal... 12 bits of resolution gives 4000+ fader levels which is likely beyond human capacity to discern between adjacent levels. .
 
Status
Not open for further replies.
Back
Top