OpenDeck is a platform suited both for prototyping and developing custom MIDI controllers compatible with any MIDI software on any OS. Platform consists of electronic part (PCB), software running on MCU and web configuration tool which communicates with the board directly via MIDI protocol.
OpenDeck platform supports the following components:
Buttons
Encoders
LEDs (single color or RGB)
Potentiometers
FSRs (force-sensitive resistors)
I2C OLED/LCD displays
OpenDeck firmware also runs on Arduino Micro, Arduino Leonardo, Arduino Uno, Arduino Mega2560 and Teensy++ 2.0. Support for ARM-based deveopment boards is coming soon.
The platform allows hassle-free building of MIDI controllers and their configuration via MIDI System Exclusive messages and Web interface, without any need of reprogramming the chip.
Updated 2018-11-21
The hardware for official OpenDeck board:
USB MIDI
DIN MIDI (in/out)
64 inputs for buttons / 32 inputs for encoders
32 analogue inputs
48 outputs for single color LEDs or 16 RGB LEDs (RGB LED is actually three LEDs)
Power supply via USB B cable.
Comprehensive documentation is available on GitHub.
Configuration can be performed either via SysEx messages, or using WebMIDI configuration utility. Below are some screenshots of utility:
Will it be possible to use seven segment LED displays like with NI’s Traktor Kontrol X1 Mk2? Was considering the UMC32+M for a DIY MIDI controller project, even though it didn’t have it, but having this would sway me towards your project, as none of the other options out there bar an Arduino setup have this.
Absolutely yes, however, I really want to get the basics done right first. The project is built with modularity in mind, I’m planning to have some more features as well. Also worth of mentioning is that this will probably take couple of months before being production ready, so if you’re in a hurry I would sugest looking elsewhere for the time being. Glad you’re interested!
Thanks! Yeah, think my project will take a while. More or less just in the design phase, sketching layouts and taking into account what functions I want to have access to via the controller without needing to touch the laptop, so might take some time to work out a final design and what inputs and outputs would be needed.
Separate. This current board has MINUMUM of 16 analogue inpputs, 32 outputs and 32 inputs. There’s also 4 additional IO, so that you can expand button/LED matrix to, I don’t know, say, 2 more button and 2 more LED rows, resulting in 48 inputs/outputs, or you can use all 4 to add 4 more button rows (64 inputs in total). There is certain flexibility. Number of analogue inputs is fixed to 16. Those are all abilities of board, the software actually supports much more.
Cool project. Did you use the I2C pins for part of the multiplex? I think on
Pro mini they pop out the middle of the board? It would be great if those
were free, so things like MCP23017 could be added for LED display modules,
or other switches or… who knows what. I understand, if you had to use them, but
it would be a bonus if they are free.
I’ll try to look at your details and schematic when i’m at a proper computer.
This is all great stuff, and I admire how much work you’ve put into it so far. It seems like a very robust solution!
If you’re looking for features to add, I have a couple suggestions…
For pots, it would be nice to define an upper and lower limit that isn’t 0 and 127 (for instance 45 and 115). This function would not create “dead zones” on the pot - instead it would interpolate the defined range across the pot’s entire length of travel. This would be modified by the invert command as well. The use case would be to limit the range to only “useful” values when manipulating an effect.
For encoders, it would be useful to have settings for sensitivity, acceleration, and message type. Sensitivity would act as a multiplier or divider for the number of “ticks” in the natural resolution of the encoder (25 pulses per revolution for example). This could be used to not only help address “slow” pots, but also to slow down higher resolution pots (8 bit or higher). Acceleration would act similarly to sensitivity, except it would ramp resolution up based on how quickly the pot is being twisted. This would allow the encoder to have fine control over a parameter but allow for more radical value changes. Message type would allow the user to select what KIND of relative message is being sent from the encoder (binary offset, 2s comp, etc). Sometimes one is more suited to the task than another, and allowing the host software to set those values would be useful.
For buttons or knobs, it would be great to allow the control output message to also set a state in the controller. So a button might send 90 21 7F, but it might also send F0 00 53 43 01 00 42 00 13 01 F7 (to change the mode of button 19). Ideally it would be possible to send multiple commands of this type - allowing the user to reconfigure the controller on the fly. To take that idea even further, it would be AMAZING to allow incoming MIDI messages to trigger a similar stack of SYSEX strings. At that point, the host application could drive controller configuration based on any number of conditions (what view is selected, what effect is loaded, etc).
In any case, thanks for bringing a smile to my face this morning! Great work!
Sure I am, it’s one of the reasons I’ve opened this thread.
This seems like a straightforward thing to, consider it done for next release.
Version 1.0 of software doesn’t have any support for encoders yet, even though hardware is capable of controlling them. Initial encoder support will come soon, and when I get it done, I’m going to read your message again, to include the stuff you’ve mentioned. I’ve never dealt with proper encoders before, so support for them is probably going to take a while.
How do you suggest I do this? I mean, you certanly don’t want to change button mode each time you press it. Maybe I could add a feature to GUI (once I start working on it) to define some combination of “magic keys”, ie. press couple of keys together, certain LEDs light up to indicate that you’re in edit mode, and then you can change stuff you want. Certanly possible.
Also very much possible. Do note that I’m the only developer involved in all this, so you won’t see all these features right away in next release, but eventually you will.
So the basic use case is to allow the user to define “pages” for the controller that would allow the controls for each page to act differently. So I would define the buttons on the controller I want to switch pages, then I would program those buttons to modify the behavior of a set of controls.
So here’s a more defined use case. Let’s say I have 4 encoders arranged above my up fader in a mixer-style controller. I’m using encoders in this case because I want 2 channel strips to control 4 decks. But I also want to use one of those knobs to act as a “fine scrub” so I can line the waveform up against the play marker. To control EQs I’m going to want the knobs to output an absolute message, but when the deck isn’t playing I want one of those knobs to switch to relative so I can jog. So in this case, the play button (or the “deck is playing” message from the application) would change the behavior of that encoder.
There are actually a ton of ways I can see this being used. Typically if someone wanted to do something like this they would build a preset in MIDI Translator, or Max or something else. But I think it would be pretty handy to support in the firmware.
I see where you’re getting at. That’s going to be tricky bussiness and will require some careful code design in order to make it as simple as possible. But I definitely like your idea, and it’s now on my to-do list.
Even though it’s not commited yet, buttons can now be configured to send Program Change instead of note/CC messages.
Since I’m working on several projects right now, GUI won’t be finished any time soon - summer time is likely. I’ve also written new blog post about OpenDeck code:
