Tag Archives: midi

OpenDeck platform v1.0

You’d be forgiven for thinking that OpenDeck project is dead, as well as this blog – after all, it’s been more than a year since the last update. While it’s true that in the past year I haven’t had much time to work on the platform, last couple of months have been full of development again, and this post is an announcement of OpenDeck v1.0 – stable version of firmware, hardware and Web configuration utility. This time, I’ll concentrate on user-facing changes only – low-level changes are going to be discussed in future posts.

In case this is your first visit here, I’ll copy OpenDeck info straight from GitHub:

OpenDeck is a platform suited both for prototyping and developing custom MIDI controllers compatible with any MIDI software on any OS. Main part of the platform is board on which various components used to build a MIDI controller can be connected. The board supports the following components:

  • Buttons
  • Encoders
  • LEDs (single color or RGB)
  • Potentiometers
  • FSRs (force-sensitive resistors)

Hardware

Since my last post, OpenDeck board went through two revisions. I’ve fixed some stuff, and added some as well, however, the basic layout is exactly the same, as well as dimensions. Final version of the board is black – it sure does look nicer compared to ugly green one.

2017-01-30-16-51-26

Now there are three indicator LEDs, compared to two on last revisions. One is for power, and other two are active when there’s MIDI traffic on board (one for input and one for output). Those two LEDs serve double-purpose, as they’re both on while in bootloader mode.

On MIDI side of things, I’ve replaced 6N138 optocoupler with way-faster 6N137.

Configuration utility

This is the big news. Really big. Ever since Google announced the support for Web MIDI in Google Chrome, I wanted OpenDeck configuration utility to run inside it. Building one app which runs on any platform is definitely better than coding three different apps for Mac, Linux and Windows. Since my knowledge of web is pretty miserable, I’ve hired two guys (programmer and designer) to design and build configuration utility based on my specs. I don’t know much about low-level details of utility, but I do know it involves some magic words such as “Angular” and “Javascript”. Concept of utility is actually pretty simple – it has sidebar containing configuration blocks available on OpenDeck – MIDI, buttons, LEDs, encoders and analog stuff. It also has activity log, displaying all incoming and outgoing messages, info window and backup and restore functionality. All configuration is done using custom SysEx protocol explained here. Below are the screenshots.

screenshot859
MIDI configuration block

On MIDI screen, user can configure couple of settings related to MIDI protocol itself, as well as channels for MIDI messages used on OpenDeck. Toggling DIN MIDI in to USD MIDI out will result in all MIDI traffic received via DIN MIDI in connector being forwarded to USB MIDI out, so any older MIDI gear can be used as USB MIDI controllers using OpenDeck  board. You can read more about running status and note off messages here.

screenshot860
Button configuration block

Button window lists all buttons which are possible to configure on board. Even though board has 64 inputs for buttons, 32 analog inputs can be converted to digital inputs (that is, buttons), resulting in total of 96 possible buttons. One of the cool features of utility is that pressing the button connected to board will automatically blink the correct button ID in utility, so that you don’t have to waste time finding it. You can read about how is that accomplished here. Another cool thing is that number of buttons (or anything else) isn’t hardcoded, but generated by the utility. Before the configuration section is rendered, a request is sent to board asking it how many buttons are possible to configure, so utility is future-proof if I’m ever going to increase or decrease number of buttons, encoders etc.

screenshot861
Single button configuration

Clicking on certain button brings up modal window which lists all possible parameters for single button. Here, user can configure button as momentary or latching. MIDI message sent by button can be chosen as well (note or program change) and also, any MIDI ID (0-127) can be assigned to specified button. MIDI ID is used as note or program, depending on which message type is selected.

screenshot862
LED configuration block

LED configuration lists some global parameters applied to all LEDs, as well as list of all LEDs which are possible to configure. OpenDeck supports 48 single-color LEDs, or 16 RGB LEDs, since RGB LED is actually three LEDs in single case.

screenshot863
Single LED configuration

Any LED can have assigned any activation note (0-127). When local control is disabled, LED is controlled with received MIDI note and velocity. You can read more about LED control here. When enabled, any button which sends note same as activation note will control the LED instead. LED can also be configured as RGB LED. Last two options are used for testing LED states (when RGB LED is enabled, different colors can be picked from state test field).

screenshot864
Encoder configuration block

Encoder section displays total of 32 encoders. 64 digital inputs available on OpenDeck can be used to connect those 32 encoders (one encoder takes 2 digital inputs). Note that analog inputs cannot be used to connect encoders.

screenshot868
Single encoder configuration

Encoders need to be specifically enabled in order to function. Encoders send CC messages, and any CC number can be assigned to specific encoder (0-127). Two encoding modes are available: 7Fh01h and 3Fh41h, which can also be inverted.

screenshot865
Analog configuration block

Analog configuration section displays total of 32 components.

screenshot866
Single analog component configuration

Analog components need to be enabled in order to function. This is to avoid junk coming out of floating analog input when nothing is connected to it. All analog inputs can be configured as potentiometers, FSRs and buttons. Default is potentiometer. Any MIDI ID can be assigned (0-127). Potentiometer type will send CC messages with CC number specified as MIDI ID, FSR type will send MIDI note event with note being MIDI ID, and button type will send note event specified in button configuration section. Invert option applies only when potentiometer is active type. Lower and upper CC limits can be used to scale CC values coming from potentiometer and FSR.

screenshot867
Info window

Info window contains some basic info about the board (firmware and hardware version). Checking for updates is done by comparing last tag on OpenDeck GitHub to firmware version currently present on board, which is a very cool feature. Other options include rebooting the board, factory reset and bootloader mode, which is used for firmware update process.

I can say I’m very proud of configuration utility, as it’s one of the first WebMIDI apps used for configuration using SysEx messages! Building a MIDI controller sure does seem easy now. I haven’t had the chance of testing it on Linux distros yet, but it works (mostly) flawlessly on Windows and Mac OS X – mostly because of WebMIDI still being finicky. For instance, MIDI connection sometimes won’t be detected, and leaving the utility idle for some time can sometimes lead to issues. On top of that, Google also requires SSL connection when using SysEx messages via WebMIDI which is a real PITA. Really Google? I hope those issues will be resolved one day, but for now, I can live with it. I also hope other Web browsers will include support for WebMIDI soon – not everyone likes Chrome. There is some activity with WebMIDI implementation in Firefox, though.

Documentation

Undocumented code is worthless. I’ve written extensive wiki on OpenDeck GitHub, so you can check entire documentation here – everything from schematics, connection diagrams, SysEx protocol, firmware update process etc.

Open Source

Most of OpenDeck really is open. I’ve done my best to write clean and efficient code and document entire project. Exceptions to this are board design (gerber files) and Web utility. Those two things are truly custom solutions, and OpenDeck is a platform open enough to be used without them, since my GitHub contains complete schematics and full documentation on SysEx protocol. Maybe someone will build a better board and better configuration app – who knows? In the meantime, my board and utility really are the only incentives for someone to actually spend any money on OpenDeck. At the end of the day, whenever someone buys it, it will make me invest more time into platform, which translates to less bugs, more features and possibly new products. So far, development of platform has been pretty slow. Supporting it will definitely change that.

Availability

Now that board, firmware and configuration utility are ready, you can contact me for pre-order. Pre-order here means that I’ll send the boards to manufacturing once I receive at least 10 pre-orders. I’m selling the board for 111€. Package contains:

  1. Board
  2. USB cable
  3. MIDI cable
  4. Access to online web utility
  5. One year guarantee

Bugs and feature requests can always be reported here.

Thanks for reading!

Building Ceylon

This is a long overdue post about Ceylon, another Shantea Controls controller, only this time, one that I’ve built for myself. Of course, it’s based on OpenDeck platform.

Ceylon was actually built about three months ago. Reason why I haven’t written about it is a combination of things really. First, it was in a beta period for more than a month, and after that I just didn’t have much time to write posts, as I was really busy (and still am) with other projects that I’ll hopefully write about soon.

Name and design

Let’s start with a name. After Anandamidi and Sensimidia, it was time to bring back tea in Shantea Controls again. So, Ceylon is actually well-known high-quality tea originating from Sri Lanka, former British colony known as Ceylon (hence the name). There are couple of variations of it, black one being my favorite (with some spices of course, that is, loads of ginger).

10678704_306345016225412_2880265286737813749_n

Picture above is a rendered drawing of Ceylon design. Numbers around the circle are coordinates of Kandy District, heartland of tea production in Sri Lanka. So there you have it, a Ceylon story!

Layout

Since Tannin was my only controller so far, I’ve mapped nearly every function I need, so when I started designing my second controller, I wanted something really simple that would complement Tannin well. There was no need for a complicated layout or redundant functions, that’s why its design is really minimal. There are 3 faders, 12 orange LEDs for some eye-candy, err, I mean VU-meter, shift button, two potentiometers above faders for gain control, six anti-vandal switches with blue LEDs, and disk. Most significant change here from Tannin is the use of encoder. Well, not your usual encoder though. It’s a salvaged HDD motor acting to be encoder actually.

Plate

Ceylon is first controller I’ve built which doesn’t use standard black/white Gravoply plate, as I grew tired of it. Instead, I’ve picked blue plate this time, and it looks really gorgeous.

WP_20150224_028

I also redesigned USB plate.

WP_20150224_017

Case is white again, just like Tannin.

The disk

As I’ve already stated, only thing new in Ceylon is the disk. So, how does it work? The motor in mechanical hard disk generates phase-shifted sinusoidal waveforms when spinned. The faster you spin it, larger the amplitude and frequency of waveforms. By examing waveforms, you can determine disk direction, which is what I needed. There are couple of issues with this:

1) Signal amplitude is way too low to be sampled directly by a microcontroller, unless you spin the disk real fast, which is kind of missing the point of whole setup as you want fine grained control. My measurements showed that disk generates +-500mV when spinned at maximum speed (maximum being somewhat subjective term, I spinned it by hand).

2) For encoders, you don’t actually need analog signals, but digital ones. By examining output data from two encoder pins, you can easily determine its direction. Those two outputs are called quadrature outputs, as they are 90 degrees out of phase.

600px-Quadrature_Diagram.svg

ScreenShot209

Making the signals digital

Basically, what this setup needed was ADC (analog-to-digital converter). For this use, I’ve chosen LM339, a very cheap, available and popular comparator. LM339 contains four comparators in a package, making it suitable for this setup, as I needed only two. Comparator takes two inputs, and simply determines which one is bigger. If voltage on non-inverting input (+) is larger than voltage on inverting input (-), output is digital 1, or Vcc, and if non-inverting input is smaller than inverting input, output is digital 0, or -Vcc (in this case GND). Very simple. But as usual, there are couple of caveats.

Issues

Connecting motor inputs directly to LM339 isn’t such a good idea, for two reasons:

1) What happens if two signals are very close to each other? Comparator would output bunch of ones and zeros very fast, which is actually junk, so you get unreliable results.

2) According to LM339 datasheet, you cannot apply more than -0.3V at either of its inputs. This is a problem, as disk actually outputs about -0.5V when spinned real fast.

Hysteresis

It took me really long to figure out what hysteresis actually is, but it’s actually really simple. Using hysteresis on comparator, you are creating two thresholds for generating two output states, that is, you are setting one threshold for output to be Vcc, and second one to be -Vcc, that is GND. This is achived by applying positive feedback from output back to input, using two resistors. Since signal from motor is really low, I’ve designed hysteresis for low values, just to keep signal from circling around switch point. Hysteresis is calculated using this formula:

Vth+ = -VN ∙ (R1 / R2)
Vth-  = -VP ∙ (R1 / R2)

Vth is threshold voltage, Vn is negative output (in this case 0V), and Vp is positive output (+5V in this case).  I wanted to set positive threshold above 0V, and negative below -5mV, so resistor values are 1k for R1, and 1M for R2:

Vth+ = -0 * (1000/1000000)
Vth+ = 0V
Vth- = -5 * (1000/1000000)
Vth- = -5mV

So, when positive input voltage is above 0V, output is 1, and only when negative input drops below -5mV, output is 0. This way I created “dead zone”, or area where my signal can be of any value (between 0 and -5mV), without affecting the output of comparator.

250px-Smitt_hysteresis_graph.svg

Graph is showing the input signal (U), usage of comparator on that signal without hysteresis (A), and output signal from comparator with applied hysteresis (B).

2000px-Op-Amp_Schmitt_Trigger.svg

Picture above shows hysteresis setup. This is how you debounce your inputs using hysteresis, so that your output never becomes gibberish.

Voltage clipping

Now, there is one more concern. As I stated already, inputs on LM339 cannot be smaller than -0.3V. To accommodate this, I used BAT46 Schottky diode on inputs, having anode connected to ground. When the input is positive, diode doesn’t do anything as current cannot pass through. When the input is negative, diode still won’t do anything, as long as input voltage doesn’t become smaller than -0.3V. Those diodes have a voltage drop of about 0.3V (how convenient), so, when input voltage exceeds -0.3V, current will pass through diode, and voltage on comparator input will actually be voltage drop on that diode, and it will not exceed those -0.3V. Two problems solved, yay!

encoder

Software side of things

Now that I’ve taken care of hardware, it was time to actually read and process signals from motor. For this, I’ve used modified encoder library for Teensy/Arduino. Library is great as it has two really clever parts:

1) Since it’s written with Teensy/Arduino in mind, it automatically detects whether the pins on your microcontroller on which you’ve connected encoder have interrupt capability. If they do, library reads encoder using interrupts. Since HDD motor can be spinned real fast, I’ve connected both motor pins to interrupts (pins 2/3 on Arduino) in order not to miss any pulse. Pins 2 and 3 are two out of four unused pins on my OpenDeck board, so this was very convenient.

2) It has “predicting” algorithm, giving your encoder 4x more resolution. This is achieved by remembering previous state of pins, and comparing it to current state of pins with a lookup table. Lookup table contains valid encoder transitions:

ScreenShot210

This works really, really well, but since HDD motor jumped a bit when changing direction, I’ve implemented additional debouncing:

void OpenDeck::readEncoders(int32_t encoderPosition) {
if (_board == SYS_EX_BOARD_TYPE_OPEN_DECK_1) {
if (encoderPosition != oldPosition) {
if (millis() - lastSpinTime > ENCODER_DEBOUNCE_TIME) initialDebounceCounter = 0;
if (encoderPosition > oldPosition) {
if (!direction) { initialDebounceCounter = 0; direction = true; }
if (initialDebounceCounter >= ENC_STABLE_AFTER) {
sendPotCCDataCallback(127, 127, 5);
} else initialDebounceCounter++;
}
else if (encoderPosition < oldPosition) {
if (direction) { initialDebounceCounter = 0; direction = false; }
 initialDebounceCounter++;
if (initialDebounceCounter >= ENC_STABLE_AFTER) {
sendPotCCDataCallback(127, 1, 5);
} else initialDebounceCounter++;
}
oldPosition = encoderPosition;
 lastSpinTime = millis();
}
}
}

If there is a movement detected, code first checks for whether the disk hasn’t been moved for more than ENCODER_DEBOUNCE_TIME (70mS). If it hasn’t, it resets the debounce counter. This is to avoid extra pulses when disk is slowing down. After that, initialDebounceCounter variable is incremented until it reaches 1. This is to prevent disk jumping when changing direction.

So there you have it, a pretty good resolution from HDD motor for use in MIDI controller! In all honesty, its resolution is far from optical encoders, but as this is more of a proof-of-concept, I’m really satisfied with results.

LEDs on anti-vandal switches

This was another issue that I had while building Ceylon. Anti vandal switches (the ones around the disk) I had around have blue LED on them. Their pins are separated from button pins. Those button pins can be connected in NC and NO configuration, so there’s 5 pins in total. Since I’m using shared column button/LED matrix in my OpenDeck platform, I’ve connected – pin of LED and one of button pins together, going into same column, and then + pin of LED into LED row, and second button pin to button row. Nothing out of ordinary, right? Well, something weird was happening with this setup. Whenever I pressed the button, LED on it lighted up. This is not the behavior that I expected nor wanted, so for a while I had no idea what was happening. Only few days later, I’ve discovered that it doesn’t really matter where you connect + and – of the integrated LED on button, since there are 2 LEDs inside, one of which has anode on + pin, and second one on – pin.

anti vandal configuration

Okay, but why does the LED turn on when button is pressed? For this, answer is in matrix setup. LED/button matrix works by switching columns very rapidly. Only one column is active at the  time, and during that time, it is connected to GND, while others are connected to Vcc. When button is pressed, connection from microcontroller input on which button is connected goes to GND, and button press is registered, but only during the time the column is active. When column isn’t active anymore, it’s connected to Vcc. Since those switches have two LEDs inside, one of which has anode on – pin, when button is pressed, and column isn’t active, that anode is actually connected to Vcc, and LED row on microcontroller starts acting like current sink, so LED is lighted up.

switch

In order to solve this, I’ve placed Schottky diode (to minimize voltage drop) between LED anodes and microcontroller LED row pin, so that the current is blocked for second LED inside switches.

switch2

Demo

So, to conclude this post, here’s a short video of Ceylon in action, together with Tannin.

And also some higher quality pictures of Ceylon.

IMG_8551 IMG_8553 IMG_8565

Thanks for reading!

Building OpenDeck – SysEx protocol

MIDI is a great protocol. One if its best features is System Exclusive message – the only type of message in MIDI protocol which doesn’t have defined message length, that is, it can be dozens of bytes long, or more, given that data bytes have MSB bit set to zero (byte value is 0-127). Only thing that is defined is its start, “0xF0” and end, “0xF7”. Manufacturer ID byte (or three bytes) is what usually follows after start byte, so that only specific devices accept the message and respond to it. Everything else is optional, which means you can create your own protocol for configuring your MIDI device using nothing more than a SysEx message. Because of its undefined nature, you can even use it to add more features to MIDI itself, if you find MIDI protocol too limiting for your needs, which is kind of hard to imagine, but oh well.

SysEx is also the basis of configuring OpenDeck platform. I’ve tried to make protocol as simple as possible, so that it’s easy to understand and remember. This is the main message format:

F0 ID ID ID WISH SINGLE/ALL TYPE SUB-TYPE PARAMETER_ID NEW_PARAMETER_ID F7

Whoosh! What’s all that? I’ll try to explain every byte. As you can see, there are three ID bytes after the SysEx message start. Back when MIDI was new standard, specification said only the first byte after SysEx start is ID byte, which due to the SysEx limitation of maximum value of data byte being 127 meant that there could only be 127 MIDI manufacturers in the world (ID 0 is unassigned). That was true in first couple of years, but after a while, single byte just wasn’t enough anymore, so it was decided that three bytes could be used as ID as well. Those three bytes are actually two, since first byte is always zero. Even two bytes (just one byte more than what original specification said) are enough for more than 16k combinations, so there shouldn’t be any reason ever to increase those three bytes to four, or more. Furthermore, there is an ID reserved for educational and development purposes, which is what I should use, or at least what I thought I’d use. However, that ID prohibits use in any product released to the public, commercial or not, so that was not a deal. On the other hand, to use any other ID, you have to register and pay anual price od 200$ to MIDI Manufacturers Association. So, I decided to just use 3-byte ID and hope nobody will complain about it. I’ve checked official manufacturer ID list and luckily, nobody is using the ID I wanted. Also, given how my SysEx system works, it’s basically impossible to use it on any other device, even if it has same ID. I settled for 0x00, 0x53, 0x43 ID. That ID, as well as some other parts of my SysEx protocol is based on ASCII table. 53 in hexadecimal system means “S” in ASCII table, and 43 is “C”, SC for Shantea Controls. Easy.

WISH

Wish can have three meanings:

1) GET: Request data from controller. Code for this is 0.

2) SET: Store new data in controller. Code 0x01.

3) RESTORE: Restores default configuration for specified data, or restores every setting to factory default. Defaults can be checked in code here. Code is 0x02.

 

SINGLE/ALL

This byte specifies whether we want to get/set/restore single parameter, or all parameters for specified message type. Single code is 0, and all is 0x01. Again, really easy.

 

MESSAGE TYPE

There are several message types, and their codes are all based on ASCII table, just like ID:

1) MIDI Channel: 0x4D.

There are 5 channels in total (Button press, long button press, CC channel for pots, CC for encoders and input channel). These are their parameter codes (copied directly from here):

#define SYS_EX_MC_BUTTON_NOTE 0x00
#define SYS_EX_MC_LONG_PRESS_BUTTON_NOTE 0x01
#define SYS_EX_MC_POT_CC 0x02
#define SYS_EX_MC_ENC_CC 0x03
#define SYS_EX_MC_INPUT 0x04

2) Hardware parameter: 0x54

3 hardware parameters in total. Codes:

#define SYS_EX_HW_P_LONG_PRESS_TIME 0x00
#define SYS_EX_HW_P_BLINK_TIME 0x01
#define SYS_EX_HW_P_START_UP_SWITCH_TIME 0x02

3) Software feature: 0x53

7 features. Codes:

#define SYS_EX_SW_F_RUNNING_STATUS 0x00
#define SYS_EX_SW_F_STANDARD_NOTE_OFF 0x01
#define SYS_EX_SW_F_ENC_NOTES 0x02
#define SYS_EX_SW_F_POT_NOTES 0x03
#define SYS_EX_SW_F_LONG_PRESS 0x04
#define SYS_EX_SW_F_LED_BLINK 0x05
#define SYS_EX_SW_F_START_UP_ROUTINE 0x06

4) Hardware feature: 0x48

4 main hardware features. Codes:

#define SYS_EX_HW_F_BUTTONS 0x00
#define SYS_EX_HW_F_POTS 0x01
#define SYS_EX_HW_F_ENC 0x02
#define SYS_EX_HW_F_LEDS 0x03

5) Buttons: 0x42

6) Potentiometers: 0x50

7) Encoders: 0x45

8) LEDs: 0x4C

9) Everything: 0x0A

 

MESSAGE SUB-TYPE

Several types of message require more specific info abut their type: buttons, pots, LEDs and encoders. Subtypes are following:

Buttons: Type (code 0) / Note (code 0x01). Type is for getting/setting info about type of button. Type can either be momentary (code 0), meaning that button will send note off right after it’s released, or it can be “toggle” type, which means that pressing button will send note on, releasing it will do nothing, and pressing it again will send note off. Note is MIDI note number which button sends.

Potentiometers: Enabled (code 0) / Inverted (code 0x01) / CC # (code 0x02). All of these are pretty self-explanatory. Setting enabled bit to 1 enables the potentiometer, and 0 disables it. When poteniometer is disabled, it will not send any data. Setting inverted bit to 1 inverts the CC data coming from the pot, which means that usual 0-127 CC range transforms to 127-0. Useful when you reversed the power/ground lines on potentiometer. CC code can be anything from 0-127.

Encoders: Same logic as potentiometers.

LEDs: For now, LEDs don’t have any sub-type, which is probably going to be changed as I develop the protocol further.

Every other message type doesn’t have sub-type, which means that they require setting of sub-type byte to 0.

 

Parameter ID

ID of component we want to manipulate. Allowed IDs:

1) MIDI channels: 0-4

2) Hardware parameters: 0-2

3) Software features: 0-6

4) Hardware features: 0-3

5) Buttons: 0-63

6) Potentiometers: 0-63

7) Encoders: 0-31

8) LEDs: 0-63

 

New parameter ID

Only needed when setting new value of specified parameter. Allowed IDs:

MIDI channels: 1-16

Hardware parameters: 4-15 for long-press time (400-1500 miliseconds), 1-15 for LED blink time (100-1500 miliseconds), 1-150 for start-up LED switch time (10-1500 miliseconds).

Software features: 0-1 (enabled/disabled)

Hardware features: 0-1 (enabled/disabled)

Buttons: 0-127

Potentiometers: 0-127

Encoders: 0-127

LEDs: 0-127

Examples

This is the scenario: we want to find out on which MIDI channel are buttons sending Note data for regular presses (note that all example bytes are in fact in hexadecimal system, not decimal):

F0 00 53 43 00 00 4D 00 00 F7

Message starts with start code. After that, there are 3 bytes reserved for ID. Next comes WISH byte. Since we want to get data, code is 00. We only want single parameter, so SINGLE/ALL byte is also 00. Message type for MIDI channel is 4D, so that is next byte. MIDI channels don’t have sub-type code, so we set next byte to 0. Finally, since we want button channel for regular press, we set the last byte to 0.

Response is handled in very similiar way as request. After sending that message to controller, result is following:

F0 00 53 43 41 4D 00 01 F7

Response also starts with three ID bytes. After that comes 41 byte. 41 in hex system is “A”, and it’s chosen since it represents ACK signal, meaning that received message is correct request, and that there haven’t been any errors during data retrieval. After ACK signal, response sends message type and subtype, that is, 4D and 00 in this case. Final byte is wanted data. Since default MIDI channel is 1, byte is also 0x01. This is the result in a more graphical way (note that Hairless MIDI doesn’t display F0 and F7 bytes):

Screen Shot 08-30-14 at 09.15 PM

Next example: We want to get all MIDI channels at once.

F0 00 53 43 00 01 4D 00 F7

Very similiar to previous example, except that now we’re setting single/all (6th byte) to 1, because we want all parameters. Note that in this message, parameter ID isn’t needed.

Screen Shot 08-30-14 at 09.19 PM

Result is following:

F0 00 53 43 41 4d 00 01 02 01 02 01 

Again, similiar result as previous message, except that now there are 5 values after subtype signal, because there are 5 MIDI channels.

Now, we want to set CC channel for potentiometers to channel 2 (default is 1).

F0 00 53 43 01 00 4D 02 02 F7

5th byte is now 1, because we are setting a value. 6th byte is 0, because we are setting only one value. Following bytes are message type and sub-type, parameter of channel we want to change (code for CC channel for pots is 02), and a new value for channel, 02.

Screen Shot 08-30-14 at 09.26 PMFirst I moved potentiomer 6 for a while. App shows that CC is sent on channel 1. After that, SysEx message is received which alters CC channel to 2. Response for setting is:

F0 00 53 43 41 4d 00 01 F7 

Again, ID followed by ACK, followed by type/sub-type and final byte 1, which means controller has successfully written one new value. Note that these are permanent changes, that is, all values are written to microcontroller EEPROM, meaning that they won’t be replaced by defaults next time controller starts-up.

There is another type of message, “hello world”, used for setting up SysEx communication with controller:

F0 00 53 43 F7

If we send this message to controller, the response we would get is:

F0 00 53 43 41 F7

Which is ID followed by ACK signal. This is used for checking the device ID. If this check fails, no further SysEx communication will be allowed until the “hello world” message has correct ID.

Error messages

Each SysEx message goes through rigorous testing of each supplied byte, so it’s impossible to mess up controller with wrong values. Every time message format is wrong, controller will send error message with error code. For now, these are error codes:

Error 0: F0 46 00 F7

This is error code for wrong device ID. When you supply wrong ID code, first byte after the start is 46, which is “F” in ASCII table (F for failure), which means something has gone wrong. After error byte, next byte is error number, in this case 0. This error is the only one in which device ID isn’t sent, for obvious reasons.

Error 1: F0 00 53 43 46 01 F7

Error code for wrong WISH command. Note ID in response.

Error 2: F0 00 53 43 46 02 F7

Wrong single/all command.

Error 3: F0 00 53 43 46 03 F7

Wrong message type.

Error 4: F0 00 53 43 46 04 F7

Wrong message sub-type.

Error 5: F0 00 53 43 46 05 F7

Wrong parameter ID.

Error 6: F0 00 53 43 46 06 F7

Wrong new parameter ID.

Error 7: F0 00 53 43 46 07 F7

Message too short.

Error 8: F0 00 53 43 46 08 F7

Error while writing new data to microcontroller.

Keeping data integrity

OpenDeck code makes sure that new data is actually written to EEPROM without issues. Here is example of checking for whether MIDI channel has been written successfully:

bool OpenDeck::sysExSetMIDIchannel(uint8_t channel, uint8_t channelNumber) {

switch (channel) {

case SYS_EX_MC_BUTTON_NOTE:
_buttonNoteChannel = channelNumber;
eeprom_update_byte((uint8_t*)EEPROM_MC_BUTTON_NOTE, channelNumber);
return (channelNumber == eeprom_read_byte((uint8_t*)EEPROM_MC_BUTTON_NOTE));
break;

...

...

}

}

Function first overwrites channel currently in RAM. After that, it writes new value to EEPROM. Finally, it checks if received channel is equal to the one just written in EEPROM, so that it’s impossible to get ACK message if this step fails.

That would be all for now. Protocol is still in heavy development, and some of the stuff I’ve talked about here isn’t even implemented yet.

Announcing OpenDeck platform

In the last few days, I’ve finally put all of my ideas into one, coherent project called OpenDeck. For those of you who don’t already know, OpenDeck started as my vision of open source MIDI controller. I didn’t mean open source as just the code – it was a complete open hardware project, with vector design, electronic circuit, PCB schematic and last, but not least, the code itself freely available on my GitHub account. Eventually, OpenDeck source code got transformed into a helper library, which I happily use (it’s the base of Anandamidi and Tannin, two controllers I’ve built). I’ve spent few years tweaking it until I finally got super-stable code, so that when I build controllers, and something doesn’t really work, I am sure it’s not the code, but something hardware-related. Therefore, OpenDeck as a platform is really the only logical next step. What the hell am I talking about? Let’s see.

OpenDeck backend

The backend is actually the software which I already have. It’s split into few distinct parts:

1) OpenDeck library

This library (for now) can handle:

  • LED and button matrices
  • blink and constant mode on each LED
  • LED control via MIDI in
  • start-up animation generation
  • reading potentiometers directly connected to ATmega chip or multiplexed via external multiplexer
  • inverting the potentiometer data
  • turning potentiometers into 6-way switches (expandable)
  • both digital and analogue debouncing
  • MIDI channels selection
  • long-press button mode (buttons can be configured to send a MIDI event after they’re pressed for defined time)

For now, that’s it. As you can see, it already has lots of options, however, the features I’m planning to add are:

  • rotary encoder support
  • RGB LED support
  • anything else?

2) HardwareReadSpecific library

This library talks directly with OpenDeck library. The only thing it contains is hardware-specific code. As an example, let’s see how OpenDeck library gets reading from whole column in button matrix:

void OpenDeck::readButtons() {

uint8_t buttonState = 0;
uint8_t rowState = HardwareReadSpecific::readButtons();

...

}
 
And readButtons() in HardwareReadSpecific looks like this (example taken from Tannin controller):
uint8_t HardwareReadSpecific::readButtons() {
     
    //get the readings from all the rows
    return (PINB &amp; 0x0F);
     
    }
So, OpenDeck library contains only generic stuff, while HardwareReadSpecific deals directly with the hardware. This kind of implementation allows for extremly simple change of microcontroller used in the project.
 
Apart from dealing with hardware directly, HardwareReadSpecific library also contains lots of switches. Using them, you can easily enable or disable LED or button matrix altogether, define debouncing time, blink duration and much more. Code is up on my GitHub account, so can check it yourself.
 

3) MIDI library

 
This is the only part of the code which isn’t written by myself, although I’ve trimmed out the parts from it which I don’t need. This library is responsible for actually sending and receiving MIDI data. The most powerful part of it is exactly the incoming data parser. Library is written by Francois Best, and you can find the latest version of it on his GitHub account. It’s worth of mention that latest version is 4.2, while I’m using older-but-proven modification of 3.2 version (also available on my GitHub, redistibuted under GPLv3 conditions).
 

4) main file

 
If you’re ever done any programming in your life, you already know what main file is. If you haven’t, then you’ve also probably skipped this entire section. But, simply put, main is where your code starts. In microcontroller programming, it usually has two distinctive parts: setup, in which you call constructors, initialise everything you need, and run some code which only runs on start-up, such as LED animation, and loop, which runs until you disconnect power from your microcontroller. This file calls OpenDeck functions. After OpenDeck library gets stable data from inputs, it uses callbacks to MIDI library to actually send the data, or store the incoming stuff.
 
I’m really happy about the modularity of my code, since this way, I can develop each of the four parts independently, without breaking whole code.
 

OpenDeck frontend

Okay, how about we make it interesting? Even though I’ve went through pretty-much all of the code which powers my MIDI controllers, I consider it only to be backend. So, what would be frontend? GUI application, of course! If all of this sounds familiar, well then, it should, because Livid Instruments makes everything I’m talking about in this entire post. Go check it yourself. What they’ve done is pretty amazing. They’ve got a PCB board on which you can connect anything you like, pots, encoders, LEDs etc. It all comes pre-programmed, it’s MIDI compliant, and it also has GUI configuration. There’s only two problems really:

1) Only two PCB sizes (one costs 49 and other is 189$, which makes for quite a gap for projects of mid-size)

2) It’s not open-sourced

Therefore, I’m basically building clean-room implementation based on what I already have. As I’ve already explained, my backend is very modular, so adapting it for other hardware only requires small changes in HardwareReadSpecific library. As far as PCB is concerned, I’ve created design for reference board, which I’ll send to manufacturing after I’m done checking for any errors. The board contains total of 16 analogue inputs, 32 digital inputs (32 buttons or 16 enoders, once I’m done implementing it in software), and 32 digital outputs for LEDs. What powers that board is Arduino Pro Mini, great little tool (also very, very cheap). Board also has headers for my USB MIDI PCB board, which I’ve talked about in my last post. Notice, however, that this is only reference board. Final version will have both ATmega and AU-123 chip integrated into one board, so that there’s no messing with drivers or converters, straight plug-and-play. I’m also planning to have ICSP header, for those feeling adventurous, so that even the ATmega chip is reprogrammable. Of course, board design, as with circuit schematic is going to be freely available, just like software itself.

GUI

I’m only laying ideas here, I don’t even have design mockups yet, however, these are the features which I’m initially planning to have in my configuration software:

  • Testing of whole controller, that is, checking for whether all buttons, encoders, LEDs and pots actually work
  • Controller configuration, which would involve everything from MIDI channel selection, flipping of potentiometer data (or anything else), start-up animation generation etc.
  • Controller programming via custom SysEx messages (that could be a challenge)

I am planning to have GUI running across all platforms, but since I only use Windows, that’s going to be a priority. Also, because of cross-platform availability, source is probably going to be written in Java, unless someone has better ideas. While we’re at it, this whole thing is a pretty big project, so I am looking for contributors. If you’re feeling you can help me developing modular, open hardware MIDI building platform, please let me know!

Building Anandamidi, part 4

This is the last post about Anandamidi, I promise! So, in case you forgot, this is the remaining stuff to finish the controller:

  1. Painting the case
  2. Interfacing Arduino with separate USB MIDI chip on separate PCB (Altmustech AU-123)

1) Painting the case

Fairly easy part. I’ve simply bought black spray for wood and sprayed the case 3-4 times. Looks really cool!

OLYMPUS DIGITAL CAMERA

Thing I haven’t mentioned before is the cable plate and the cable itself. I bought several of these USB cables off eBay:OLYMPUS DIGITAL CAMERA

I’ve cut off the mini-b part of cable and replaced it with 4 cables with female headers on them, so that I can simply plug it to USB MIDI or serial conversion board. Since just screwing that cable directly on wooden case would look rather ugly, I’ve also designed a cable plate board, made from same Gravoply board as the main plate.

OLYMPUS DIGITAL CAMERAMuch nicer, although I’m not too happy with screws on that plate (I haven’t had anything else). Right, let’s move on to #2.

2) USB MIDI board

OLYMPUS DIGITAL CAMERAThere were more than several issues with this thing, as usual. After I received the PCBs, I asked a friend to help me solder that MIDI chip, since I’ve never soldered SMD component before, plus I don’t have necessary equipment for that job. After we soldered everything, connecting the board to PC did nothing. No errors, no anything. Checked everything few times, but I couldn’t find the error. Grrr! Since that didn’t work, I’ve decided to give the controller to the guy for whom I was building it without that board. Instead, there’s simple CP2102 serial module inside the Anandamidi at the moment. Everything is the same, except that way you need to install drivers (atleast if you’re on Windows), install virtual midi port and an app which converts serial messages from Arduino to MIDI. Couple of extra unnecessary layers, but it works without issues. After I got home, I spent few more days trying to figure out where I did mistake. Eventually, I figured I used capacitors far too large to be put in parallel with 12MHz crystal which MIDI chip needs. I bought 22µF tantalum caps, simply because the official documentation said only “22” for two crystal caps, so I assumed they meant microfarads. Did I mention how expensive tantalum caps are? Very. Tantalum caps are very expensive. Oh well. What I needed was 22pF caps, so after I bought them, suddenly everything worked. Hooray! Windows happily reported it found new USB MIDI device. Awesome. Unfortunately, issues didn’t end here.

Testing the board

For first try, I only connected TX pin from Arduino to RX pin to that board, so I was only able to send data from Arduino to PC. It worked without any issue whatsoever, so I assumed sending MIDI data to that chip would work as well. Wrong. I’ve tried to send some  MIDI messages to Arduino via that chip, only to get some gibberish values. Checked everything more than dozen of times, didn’t find anything wrong. So, I went back to reading the AU-123 documentation (after things don’t work, RTFM, right?) and noticed something interesting:

ScreenShot022

Active high? What the hell is that? Apparently, pins on microcontrollers can be either active high or active low. Active high means that HIGH signal (usually +5V) represents binary 1 and vice versa. Active low is exactly the opposite: +5V signal represents binary 0 and 0V represents binary 1. After some more investigation, I learned that USART pins on AVRs are active low, meaning that I need inverter if I want to interface them with active high signals. That was also the reason I got gibberish value on Arduino end without the inversion. Obviously, there’s more than several ways to invert digital signal. First I tried with NAND gates (74HCT00 chip) – worked! I simply connected one input of single NAND gate to +5V, and other input was the TX pin from AU-123 chip. Output from gate was inverted, so I connected it directly to Arduino RX pin. While this solution works, that chip contains 4 NAND gates and has 16 pins, and I only need one input on gate, so it’s a waste of chip. Instead, I went with transistor solution (2n2222):

9102

Really simple schematic and works just like the NAND gate solution. Finally, the MIDI USB board is fully fuctional.

Controller demo

Since everything works, here’s a video with Anandamidi, and my first controller, Tannin. Note that this was recorded before the case was painted. Enjoy.