Show Posts
Pages: [1] 2 3 ... 18
1  Community / Exhibition / Gallery / OpenDeck MIDI platform on: September 18, 2014, 03:06:13 am
OpenDeck platform is my effort to create an easy-to-use MIDI building software/hardware. For now, it is a combination of Arduino software and PCB boards, and soon it will be coupled by a GUI application. In essence, open-source version of Livid Instruments Brain, but with less functionality (at least for now).

Arduino firmware enables you to connect array of buttons, pots and LEDs to your circuit and have them running MIDI in no-time. Software solves all issues of building MIDI controller, such as MIDI In handling, digital and analogue debouncing etc. It's also worth of mention that the code doesn't run on Arduino core libraries, but on Ownduino. Ownduino is my minimal fork of Arduino core, with only a couple of functions from Arduino, and some of my own. Hardware control is handled using direct port access, for better performance. Ownduino code is available here. Code also makes heavy use of my modification of Arduino MIDI library v3.2.

The reference board houses Arduino Pro Mini as its brain. It enables connection of 32 buttons and 32 LEDs connected in a matrix using shared columns, 16 potentiomeres (2 4051 chips), and there's also 4 free pins on board, A, B, C and D, which can be configured as inputs or outputs, resulting in a extra button or LED row (although external components are then required, resistor for LED row, and diodes for button row). Only exception is pin C, which can be only configured as output, since that's pin 13 on Arduino. All configuration is done using MIDI System Exlusive.



First revision of USB MIDI board looked like this (2nd is in manufacturing process right now)

To run MIDI, there are two options for now:

1) Pure hardware MIDI
In my GitHub repo, there are PCB designs of both OpenDeck reference board and USB MIDI board, which houses Altmustech AU-123 MIDI chip. The board connects to Arduino via +5V/GND/TX/RX pins and shows on PC as USB2.0-MIDI.

2) MIDI emulation
It's also possible to install virtual MIDI cable on PC (such as loopbe) and serial-to-midi converter (such as hairless-midi) to run OpenDeck software.

Here's a demonstration of controller configuration running this software:

Schematics, PCB design, source code, part list and documentation is available on GitHub:

There's also some more info about the project on my blog:
2  Using Arduino / Programming Questions / Re: Clear serial buffer after transmission? on: September 08, 2014, 05:57:10 am
MIDI library then sends it to serial buffer
one byte at a time. As soon as the first one hits the outgoing buffer, interrupts are triggered to send the data in the outgoing buffer.

When the outgoing buffer is full, write() blocks until there is room.

I can't imagine why changing the outgoing buffer size made any difference.

Here's some screenshots then. So, my project is a MIDI controller capable of understanding SysEx messages. Depending on received messages, Arduino either changes some data inside EEPROM (SET command), or it reads data from 328p and sends it back to MIDI app (GET command). In this scenario, I want to find out MIDI notes for each of 64 buttons. Response is SysEx start (1 byte), 3 ID bytes, 4 other bytes used to determine message type and 1 byte for each button. So that's 73 bytes in total. First attachment shows what I get when serial buffer is set to 32 bytes. Response is 33 bytes long instead of 73. Second attachment shows exactly the same message being sent to Arduino, only with 255 bytes of serial buffer. No other code changes. Works just fine, without any warning.
3  Using Arduino / Programming Questions / Re: Clear serial buffer after transmission? on: September 08, 2014, 05:25:51 am
How should I handle this?

Without seeing your code? Not chance of providing any real help.

Well there's really not much to see.

void sendSysExData(uint8_t *sysExArray, uint8_t size)   {

    MIDI.sendSysEx(size, sysExArray, false);


I'm sending array of 70 bytes to that function. MIDI library then sends it to serial buffer:

/*! \brief Generate and send a System Exclusive frame.
 \param length The size of the array to send
 \param array The byte array containing the data to send
 \param ArrayContainsBoundaries  When set to 'true', 0xF0 & 0xF7 bytes (start & stop SysEx) will NOT be sent (and therefore must be included in the array).
 default value is set to 'false' for compatibility with previous versions of the library.
void MIDI_Class::sendSysEx(int length,
   const byte *const array,
   bool ArrayContainsBoundaries)

if (ArrayContainsBoundaries == false) {


for (int i=0;i<length;++i) {




else {

for (int i=0;i<length;++i) {




mRunningStatus_TX = InvalidType;

4  Using Arduino / Programming Questions / Clear serial buffer after transmission? on: September 08, 2014, 05:11:52 am
Here's the issue I'm having. I want to send serial message to PC. Its size is about 70 bytes.

The problem:
It doesn't work.

The fix:
I've increased size of serial buffer to 255 (way too much, I know, but it was just a test), and it started working.

So, what does really happen here? When my code starts filling outgoing serial buffer, doesn't interrupt fire immediately, which sends data to USART, and also automatically starts deleting data from buffer after transmission? How should I handle this?
5  Using Arduino / Programming Questions / Re: Inheritance, virtual function... or something? on: August 10, 2014, 01:50:56 pm
Virtual functions sounded good to me until I found out (well, that is at least what all the examples I've found are showing) their use is when you want to create a derived class from your base class. I don't want to do that. I only have one class.
6  Using Arduino / Programming Questions / Inheritance, virtual function... or something? on: August 10, 2014, 05:32:44 am
I've written a fairly big library which deals with potentiometers, buttons, LEDs, MIDI etc. Now, there is a part of that library which deals directly with hardware. I've managed to "separate" that part from library and I've put the hardware control functions within my main.cpp (I'm not using any Arduino libs). Here's how it works:

This is a function which switches columns in a matrix (in my library):

void OpenDeck::nextColumn()   {


if (column == _numberOfColumns) column = 0;


//increment column


So, before switching to another column, it first turns off all LED rows off, and then activates next column. So, where are those functions? Within my main.cpp. I've used callbacks to handle this:



//switch to next matrix column
void activateColumn(uint8_t column)  {

//column switching is controlled by 74HC238 decoder
PORTC &= 0b11000111;
PORTC |= (0b11000111 | (column << 3));


//control select pins on mux
void setMuxOutput(uint8_t muxInput) {

PORTC &= 0b11111000;
PORTC |= muxInput;


There are way more functions dealing with hardware, but this should be enough for an example. So, while this works, I find it be a bit tedious: I have to set callback handler, implement it, and also write a chunk of code within my library to make that stuff work. Is there a better way for achieving this? I remember when we coded in Java on college couple of years ago, I don't remember how was it called, but you could define a function in your library with a certain keyword, and any time you made an object in your main program, you had to implement that function. Is something like that possible in AVR C?
7  Using Arduino / Microcontrollers / Re: Pro Mini programming with USBasp on: July 31, 2014, 01:50:33 pm
Ah, I see, thanks. What does that "cannot set SCK period" error even measn then? Because I can upload new firmware on chip just fine. Also, how can I check fuse settings with avrdude? It lists all three as 0.
8  Using Arduino / Microcontrollers / Pro Mini programming with USBasp on: July 31, 2014, 12:11:45 pm
I'm not really sure if this is intended behavior, or something is wrong. I've tried to program Arduino Pro Mini using USBasp programmer I bought from eBay. Every connection is okay. As soon as I connect USBasp to USB (and Pro Mini is attached to USBasp), LED on pin 13 on Pro Mini starts blinking really, really fast. Do note that I can program the chip with no issues. I've uploaded basic blink sketch to Pro Mini using USBasp, but LED 13 is blinking really fast, so nothing changed. Then I tried to unplug Pro Mini from USBasp, and tried to power it using only +5V and GND connections, and LED was blinking like in sketch I've uploaded, meaning that code is running just fine. I don't know why the LED blinks all the time insanely fast while Pro Mini is connected to USBasp. Here's output from avrdude:

D:\Applications\AVRdude>avrdude.exe -c usbasp -v -v -pm328p -u -U flash:w:Blink.

avrdude.exe: Version 6.1, compiled on Mar 13 2014 at 00:09:49
             Copyright (c) 2000-2005 Brian Dean,
             Copyright (c) 2007-2014 Joerg Wunsch

             System wide configuration file is "D:\Applications\AVRdude\avrdude.

             Using Port                    : usb
             Using Programmer              : usbasp
avrdude.exe: seen device from vendor -><-
avrdude.exe: seen product ->USBasp<-
             AVR Part                      : ATmega328P
             Chip Erase delay              : 9000 us
             PAGEL                         : PD7
             BS2                           : PC2
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             serial program mode           : yes
             parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             ByteDelay                     : 0
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                      Block Poll               Page
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW
 MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ -----
 ----- ---------
               eeprom        65    20     4    0 no       1024    4      0  3600
  3600 0xff 0xff
               flash         65     6   128    0 yes     32768  128    256  4500
  4500 0xff 0xff
               lfuse          0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               hfuse          0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               efuse          0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               lock           0     0     0    0 no          1    0      0  4500
  4500 0x00 0x00
               calibration    0     0     0    0 no          1    0      0     0
     0 0x00 0x00
               signature      0     0     0    0 no          3    0      0     0
     0 0x00 0x00

             Programmer Type : usbasp
             Description     : USBasp,

avrdude.exe: auto set sck period (because given equals null)
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware up
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be per
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: auto set sck period (because given equals null)
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware up
avrdude.exe: reading input file "Blink.hex"
avrdude.exe: input file Blink.hex auto detected as Intel Hex
avrdude.exe: writing flash (180 bytes):

Writing | ################################################## | 100% 0.17s

avrdude.exe: 180 bytes of flash written
avrdude.exe: verifying flash memory against Blink.hex:
avrdude.exe: load data flash data from input file Blink.hex:
avrdude.exe: input file Blink.hex auto detected as Intel Hex
avrdude.exe: input file Blink.hex contains 180 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.16s

avrdude.exe: verifying ...
avrdude.exe: 180 bytes of flash verified

avrdude.exe done.  Thank you.
9  Using Arduino / General Electronics / Re: 2n2222 Inverter circuit on: June 25, 2014, 08:32:10 am
I connected the AVR RX pin to wrong place, ugh. Working now! With NAND solution I simply connected one input of gate to +5V, and the other was TX pin from MIDI chip. USART RX pin was connected to NAND gate output.
10  Using Arduino / General Electronics / 2n2222 Inverter circuit on: June 25, 2014, 08:11:19 am
I've got USB MIDI chip, TTL compatible, which connects to USART pins on Arduino. Sending MIDI data from Arduino to that chip (which in turns sends received data to PC via USB) works without any additionalo circutry. However, MIDI Out on that MIDI chip is marked as active high, while AVR USART pins are active low, therefore, in  order to send data to Arduino via that chip, I need some kind of inverter. Official documentation for that chip recommends 7400 NAND gates. I've tried that and it works without any issues. However, given that 7400 is a 16-pin DIP with 4 NAND gates, most of that chip is left unused, so I figured I could use 2N2222 transistor as inverter circuit. Since I know virtually nothing about transistors, I have no idea how am I supposed to connect. it. I found this circuit somewhere on internet, however that didn't work (RX LED on Arduino isn't flashing at all). I'm guessing I should change the resistor values to something else, any advice?

11  Using Arduino / Microcontrollers / Re: Pro Mini, USB MIDI chip and sending and receiving MIDI on: June 20, 2014, 07:36:23 pm
Okay so, datasheet says for MIDI out that is an "active high" pin. Can someone please explain what does that mean? Does that require connecting the pin to +5V or some other thing?
12  Using Arduino / Microcontrollers / Pro Mini, USB MIDI chip and sending and receiving MIDI on: June 20, 2014, 02:45:55 pm
I built a MIDI controller based on Arduino Pro Mini. Everything works fine, and so far, I've used the serial conversion to MIDI. Both sending and receiving the MIDI works as expected. To explain the previous setup a bit more:

1) Pro Mini is connected to PC via CP2102 module
2) I convert serial messages from Arduino with hairless-midi application
3) I route converted messages to my MIDI software via virtual MIDI cable (loopBe30)

Everything works fine. Therefore, I ordered a USB MIDI chip, more specifically, Altmustech AU-123. I've designed a PCB for it. Datasheet (attached) says it's TTL compatible, so, only change I did in my code was to change the serial baud rate from 38400 to standard MIDI speed, 31250. I've connected RX/TX pins directly to that chip, and my PC recognizes the device as USB MIDI. A good start. Sending MIDI data from Arduino to PC via that chip works perfectly fine, however, receiving does not. It's as if the messages sent to that chip are somehow inverted, except they're not. For instance, sending MIDI note 0 on channel 1 with 127 velocity should result in following message:

144 0 127

However, on Arduino end I'm receiving this:

243 1 0

I can't find any sense in that. Any suggestions? Note that my code for this test consists merely of this:

void loop() {

if (Serial.available() > 0) Serial.write(;


If I go back to previous method, 38400 baud rate with serial-to-midi conversion, I receive the expected input on Arduino end.
13  Community / Exhibition / Gallery / Anandamidi MIDI controller on: June 04, 2014, 11:26:36 am
New MIDI controller from me. 16 buttons, 6 pots, 3 faders and 10 LEDs.

Hardware base:
Arduino Pro Mini
4051 multiplexer
button/LED matrix

Software base:
Ownduino (my own minimal implementation of some Arduino functions)
MIDI library 3.2 (with some modifications to make it more minimal)
OpenDeck library (my own matrix/pot/mux library)

Very happy about this project, I still have some minor work around the case but this is mostly it.
Source is freely available here: (source is based on that controller, it's 95% the same)


And here's a tryout video:

Way more details about the project on my blog:
14  Using Arduino / Project Guidance / Re: Choosing correct microcontroller for the job on: May 29, 2014, 02:51:05 am

Thanks! Awesome approach. However, doesn't that interrupt line require debouncing?
15  Using Arduino / Project Guidance / Re: Choosing correct microcontroller for the job on: May 28, 2014, 04:21:25 pm
I don't know if there is a shift register that outputs a low if any input is clocked in as a low. That's why I suggested the diodes in a Wired AND configuration - any button low creates an interrupt, the interrrupt pulses the latch line, and you have the input high/low states captured.

Can you draw a schematic with one chip in that configuration? I'm still having difficulties with understanding the setup.
Pages: [1] 2 3 ... 18