Building OpenDeck platform, part 1

I’ve been real quiet about this project for more than a month, but not because I haven’t done anything. Quite the opposite, I literally got consumed by work invested in this project. I realized there’s much more stuff to do than I thought. As I mentioned last time, the project consists of three distinct parts:

  1. PCB
  2. MCU software
  3. GUI application

Apart from some mockups, there’s nothing else I’ve done with GUI for the time being, so I’ll just talk about first two points.

1) PCB

I’ll repeat what I said about PCB last time: it has 32 digital inputs, 32 digital outputs and 16 analogue inputs. As far as digital stuff is concerned, it’s a simple 8×4 matrix with shared columns for both buttons and LEDs. The column switching is done via 74HC238 decoder. Its outputs are connected to ULN2803 transistor array, since Arduino alone can’t handle that much current sink when all 4 LEDs are turned on in a column. Button and LED rows are connected directly to Arduino (with 220Ohm resistor for each LED row). 16 analogue inputs are handled with two 4051 multiplexeres. All in all, fairly simple circuit. Bonus features I’ve came up with are 4 additional configurable I/O pins, which you can configure in GUI app (but not right now, since GUI isn’t finished yet, and there’s not even support for those pins in MCU code). So in essence, you could use those four pins to add two additional rows in button matrix and two rows in LED matrix, resulting in total of 48 buttons/LEDs. Or you can use all four to add 32 additional buttons. Or LEDs. There is some flexibility involved in any case. Here’s how the PCB looks:

OLYMPUS DIGITAL CAMERA

Since I’m already using it in a project I’ll talk about soon, I can tell you that everything works perfectly. No wrong connections or any electrical problem. I did manage to reverse poteniometer labeling though: pots 0-7 are actually 8-15, and vice versa. Annoying? Kinda. Deal breaker? Most certainly not. I’ve also added ground shortcuts to multiplexer inputs, so if you’re not using one of multiplexers (or both), you can quickly shortcut them to GND to avoid floating pins.

OLYMPUS DIGITAL CAMERA

That’s how the board looks like with most of the stuff soldered. There is one (hardly) visible issue: Right above of the ‘A’, ‘B’, ‘C’ and ‘D’ pins (which are those configurable pins I’ve talked about) are GND pins. I intended it to be quick way to shorcut those four pins to GND if they’re left unused, since I don’t like having any pins floating. Now, there is nothing inherently wrong with that idea, except that you can’t simply ground some pins on ATmega chips. I’ve learned it the hard way. After I’ve done all the soldering, naturally I’ve connected all four of those pins to GND since the project I’m using this board for at the moment doesn’t require them. I’ve connected the board to USB via CP2102 serial-to-usb converter, but the LED connected to pin 13 on Arduino didn’t blink at all. After you connect the board to USB, that LED blinks for 6 seconds, after which your code starts running. In this case, only the power LED got turned on, so there was apparently something fishy going on. First I simply tried to upload code to the board using serial converter, but that didn’t work. I think the message in avrdude said something along the lines of “board is not responding”, or similiar. Weird. After that, I assumed that maybe I accidentally removed the bootloader while I was playing with the Arduino couple of days earlier. I connected my USBASP programmer to the board (or more precisely, soldered the cables to pins sticking out since I had no other way of doing it) and decided to simply burn the bootloader onto the board, but that also didn’t work. I got similiar message like when I tried to upload new code via serial converter. Damn. After that, I started to wonder that maybe 10nF electrolytic cap and 0.1uF cap are too much capacitance, causing the board not to work properly, because I had the same scenario with my USB MIDI PCB (you can read about it couple of posts below). So I simply cut the 0.1uF cap at first to see what happens (that’s why the cap right next to the electrolytic cap may seem a bit weird, because later I’ve re-soldered it). Nothing. Then I almost cut the electrolytic cap as well, when it hit me. When you upload new code to your board via external programmer, you connect MOSI, MISO, SCK, reset, VCC and GND pins from programmer to ATmega. MOSI, SCK and MISO are pins 11, 12 and 13 on Arduino board. The unused ‘A’ and ‘B’ pins are actually pins 12 and 13 on Arduino. See the problem here? How the hell am I supposed to upload new code to board via pins which are connected to GND? Then I simply removed the solder shortcuted to GND pins, and magically, board worked. Another lesson learned. Apart from that, there were no other issues.

2) MCU code

There’s been many changes and optimizations in code since the last time I posted. I removed HardwareReadSpecific library since hardware control is being handled via callbacks now, so all the configuration is being done within main program now. There is added benefit of being able to compile the whole OpenDeck library as a single file and simply including it as precompiled binary in other projects, but since it’s still under heavy development, I wouldn’t have any use from it. I’ve also made a “database” of parameters in EEPROM, like MIDI channels, blink time, button notes, CC numbers etc. There’s also array of default parameters in code, so that there’s an option of performing “factory reset” of MIDI controller. I’ve saved those default parameters in PROGMEM part of ATmega memory, since I would’ve wasted limited amount of available SRAM otherwise. 1kB of EEPROM may sound like tiny amount of space, but in reality it really isn’t. You are free to check the code on my GitHub page. I still have to design my own SysEx protocol to program the controller. I hope I’ll manage to finish that in the next few days, after which I can move on to GUI app.

That would be all for now.

Advertisements

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 & 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.

Building Anandamidi, part 3

Like last time I posted here, there’s been much progress. In fact, the controller is already working, even though everything isn’t finished yet. So, let’s start where we finished last time. Faders!

Placing faders

As I’ve already stated, I had some issues with placing the faders. Main source of issues was that I didn’t have any 2mm screws to screw them to the plate. As I’ve found out, those tiny screws are incredibly hard to find, at least in my area, so I had to figure out something else.

10295343_462167303929905_355654997282426842_o

Above each fader, there is really thin piece of plastic board super-glued to its surface. Couple of mm away there is standard 3mm hole. To make it more stable (otherwise that plastic would’ve fallen off) there are wooden holders screwed really tight so that there’s no way anything can happen with faders. Wooden pieces on left/right fader are shown here only for reference, as I designed PCB to fit between those two faders, but more on that later. Pretty dirty hack, as it involves extra stuff like wooden pieces, plastic and superglue. And, as the only real constant in universe says “thou shalt not use superglue without supergluing thyself”, I managed to spill some glue on my sweat suit. 😦 So yeah, building MIDI controllers is dangerous. You have been warned.

Worth of mention is that all of this would never happen if I had those damn small screws! I eventually ordered bag of them from eBay, when I finished all this, since eBay shipping times are getting horrible lately, and I wanted to get this done as soon as possible.

PCB

I’ve done PCB schematic in EAGLE CAD, my so-far favourite PCB design application. The board houses Arduino Pro Mini, two resistors for LED rows in matrix, 16 diodes for buttons in matrix to enable multi-press, 4051 multiplexer for potentiometers and couple of capacitors to make everything run more smoothly. There’s also lot of pin headers for wiring LEDs, buttons and fader. Pretty simple schematic, but prone to errors like everything. After all, what is a project without issues? There were three issues in total with PCB, but luckily, all are solved.

OLYMPUS DIGITAL CAMERA

OLYMPUS DIGITAL CAMERA

1) The board dimensions

PCB has been designed to fit between left and right fader, to make wiring more efficient and easier. Unfortunately, I completely forgot that I have to pay attention to board height, as those 3 mm screws actually set the height limit. To my good fortune, lower dimensions were okay and upper  needed a bit of trimming with sandpaper. Luckily, I’ve checked the design in EAGLE with upper few mm cut off, to see if that would mess with ground planes. It didn’t! One issue solved.

OLYMPUS DIGITAL CAMERA

2) Button matrix and diodes wiring

This issue popped out after I’ve finished wiring all the buttons. So, I connected the controller in PC to check if everything is OK with buttons. Yes, they all worked, but eight left buttons registered as only four buttons, and same thing happened on the right side. Basically, pressing buttons next to each other showed up as same button. A bit of inspective work later, I found out I made really stupid mistake of connecting two buttons under same row and column on PCB design. Ugh!

OLYMPUS DIGITAL CAMERAThe fix consisted of soldering four buttons on the left to right side of PCB and vice versa. Not too much of a problem, but after that I had 8 wires in total soldered directly to PCB, which really broke my modular design, as I wanted each component to be un-pluggable.

3) Ground issues

This is probably the last time I’m ever going to build something with PCB without protective layers. Only reason I did it this time is because I ordered PCB from local shop from which I can get PCB done in a few days, but the prices are absurdly high compared to ITead studio, for example (I found out about that site after I already sent PCB to production, of course). Ordering 10 of those boards from ITead with protective layers, silks etc. would’ve costed me LESS than single board I used here, without any of those layers, just plain double-layered board. Ugh. Lesson learned. Anyways, after I connected pretty-much everything, the LEDs started to behave weirdly, as well as two buttons (their presses showed up like pressing couple of buttons instead of only one). Again, some investigation revelead that one of my columns in matrix-setup was connected to ground. The reason it did is because after I soldered PCB to faders, one tiny bit of PCB surface touched a piece of metal part on fader, short-circuiting that column line to ground. With protective layers this would’ve never happened. What I had to do was to un-solder faders, disconnect every wire from PCB and also to un-solder those 8 wires from issue #2 (somehow I knew sooner or later I would have to do that, things just DON’T work at first, second or third try). After that I’ve put some isolation tape across whole bottom of both faders, and also on PCB to places where I connect faders, just to be sure. Messy bussiness again, but I fixed it.

After solving all the issues with PCB, everything worked. Below the board there are two wooden pieces, put there so that I can screw the four screws to secure both the board and faders, and also to avoid bending of PCB.

The box

After I finally solved all the issues with electronics, I was still left with couple of other things. The first was the case. It’s a fairly simple wooden case, and the guy who did it has done pretty good job. Things can always be better, but sometimes they don’t have to be.

OLYMPUS DIGITAL CAMERA

Remaining stuff:

  1. Painting the case (black!)
  2. Interfacing Arduino with separate USB MIDI chip on separate PCB

More on that next time!

Building Anandamidi, part 2

Lots of progress since my last post. I got the plate, already placed most of the components, finished software and just today I made some final adjustments to PCB.

Here’s how the plate looked after I got it and after I’ve put some stuff on it:

OLYMPUS DIGITAL CAMERA

That board is really awesome, sometimes I feel it’s not worth even designing anything since the board alone looks so good with anything engraved on it. The fader screws in this picture were not actually those I prepared for Anandamidi. They’re only here since at the time I did not have them yet. LED holders are here, but they don’t contain any LEDs yet. Buttons were originally mechanical buttons, but not anymore. More on that later.

One of the advantages of having 2-plate board (plexiglass+gravoply in this case) is that you can make two different layouts for each board. I used that advantage to make holes for screws bigger on engraved board, and smaller on plexi, so that they don’t stick out. I made the same thing with buttons: round hole on plexi, square hole on top. I only wish I made those squares for buttons 0.2mm smaller so that they truly don’t move at all, even tho it’s fine like this as well, when I screwed them I hardly noticed anything.

10262113_453034611509841_5139434176467412658_n

 

Tweaking the buttons

Here’s the thing with those buttons. I had a bunch of them, back when I first started doing all this and was unaware of many different types of switches (hey, a button is a button, right?). These were mechanical, and they’re truly awful, atleast if you intend to use them on DJ controller where you need instant reaction. However, unlike most of mechanical buttons I’ve seen, these can actually be disassembled. Let’s see what’s inside!

OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA

 

Lots of stuff inside. They’re really hard-to-press because of those strings. When you press them, you push them until that small metal circle touches the pins on the cap. Some buttons react better, some worse, some react just random (no reaction at all on hard press, reaction on light press, etc.). In short, pretty crappy. However, given that they can be hacked into, plus they look really nice,  I figured I must somehow use those things instead of throwing them to garbage can (where they almost did end up few years ago when I bought over 30 of them only to find out they’re crap – they were not cheap, that’s the worst part). So, just for the kicks, I removed all that stuff inside the button and tried to put a tactile switch underneath it to see if they fit.

OLYMPUS DIGITAL CAMERA OLYMPUS DIGITAL CAMERA

 Awesome! Now all I needed was something to put inside the button instead of those strings, and something to keep that tactile switch from falling. Simple metal screws proved as great replacement. It turned out you can even screw them inside the switch, so that they don’t fall out. Wow, these buttons are truly awesome for tweaking! That’s the first part of problem, the second was to keep tactile switch below the button. It’s the best to take a look at the pictures, instead of reading an explanation:

983653_452628388217130_1167125224532009197_n 10154176_452628404883795_6039742779084255572_n 10151967_452628478217121_7552256885835806934_n

 Great. Nice looking buttons with even nicer tactile switches below them.

LEDs

LEDs were a lot simpler task. I had lots of both LEDs and metal holders for them, however, those holders don’t actually “hold” the LED in place as they should, as they tend to move a lot. Simple solution was adding a bit of heat-shrinkable tube between that plastic cap in which LED goes and LED itself. LED does need to be pushed a bit harder into the holder after that, but you don’t have to worry about whether will it move or fall out – because it won’t.

 

Pots

Only thing I added to pots are pin headers. That way the wiring is a lot easier, and if for some reason pot fails, or you (for whatever reason) want to unplug it, then you just do. No need to unsolder, then solder again etc. Plug and play.

1925296_451801791633123_6057736853610738043_n

I already did some soldering work to LEDs. Since they work in matrix (like buttons), each column of LEDs on Anandamidi has a single row, which simplifies soldering a lot.

Only components not there yet are faders. They are kind of tricky, and I had some issues with deciding how to screw them, but more on that in next part.

Building Anandamidi controller, part 1

Anandamidi, MIDI controller with a strange name, is my latest project. Guy for whom I’m building it sent me basic layout and a name, while I’m working on everything else, from design (which always come first) to electronics and programming.

Name

Let’s explain the name first. “Anandamide is a molecule that plays a role in many bodily activities, including appetite, memory, pain, depression, and fertility – hence its name, which is derived from the word ‘ananda’ which means ‘extreme delight’ or ‘bliss’ in the Sanskrit language” (Source). The molecule looks like this:

 

Anandamide molecule

 

Layout

Moving on to layout. Project is fairly simple, as far as component number is concerned. It consists of 8 switches, 2 rows and 4 columns on the left side of controller and another 8 on the right side. Middle part consists of two vertically placed faders, with 5 LEDs in column next to each of them. Next to each LED column are 3 potentiometers. Below that is another horizontally placed fader. That’s it actually.

 

Design

After few days of playing in CorelDraw, this is what I’ve come up with:

Anandamidi

I’m very fond of Ace Futurism font, so I’m using it almost exclusively in my designs. You can get font for free here. Anandamide molecule is used around the controller name, along with the logo from the guy who ordered it inside it.

Shantea Controls is a name for a imaginary company which builds custom MIDI controllers, and the sole employee is me.) The leaf represents Camelia Sinensis leafs, a plant used for production of green, black and white teas (hence the “tea” in Shantea).

 

Plate

The plate actually consists of two parts. First is black 3mm thick plexiglass on which black Gravoply plate is glued, resulting in a very professional looking product. The Gravoply board is then engraved with laser CNC, so the final look is pretty much identical to the picture posted above.

That would be it for part 1, next time I’ll talk about some quirks and hacks involved into placement of components, among other things.

Commit 1

First blog post here, so I just might explain what it’s all about and what I do. I started building my first MIDI controller around 4 years ago, mostly out of the frustration with M-Audio X-Session Pro. It lacked in features (okay, it’s not really expensive, but still) and would often just stop working for some reason. After I tried to search for better controller, it turned out I haven’t had that much money for controller with all the features I wanted. Searching around for videos on Youtube I found out there is this thing called Arduino and that people, among other things, use it to build their own home-made controllers. Wow! A DIY controller! From that moment I knew I’m going to build myself one. It did not matter to me that my knowledge for electronics was 0 at that point, or that I haven’t even understood what is MIDI, or that I didn’t know what that Arduino and microcontroller are. I knew what I wanted and I was about to use any resource available to get my hands dirty and build that thing. I haven’t realised that during my learning process I’m going to learn things I never thought I’ll need, such as designing electronic circuits, PCBs, drawing in vector software or programming microcontrollers. I guess it all boils down to your will and how much of yourself you’re willing to put in things that you do.

My first project was a bit of overkill, too many stuff on it (buttons, LEDs, faders, rotary encoders…) so I never managed to finish it, mostly due to the lack of money I was going to save to build DIY controller in the first place. Oh universe. Nevertheless, I learned very much on that project, so whoever told you you should start with simple things, was wrong. 🙂 At first I used Arduino Uno, then Leonardo, then Nano and finally Pro Mini (keeps getting smaller). In the future I’m probably going to use my custom built Arduino since those boards do come with some limitations. I figured that out couple of years after using it.

So, I’m going to write here about my designs, programming, post finished controllers (which I’m building for others as well, for a price of course) and everything else involved in the build process. Phew! Lenghty post.