BLE MIDI kit dev blog


Hi all. My last big dev blog was the Ukulele build log, so I figured I’d start up another.

At the beginning of the year, I decided on a goal to sell something by the end of the year. I didn’t give myself many parameters, and I could probably cheat, but in my heart I know the sort of things I want to achieve.

  1. I want to create something new. Doesn’t have to be something completely novel, just at minimum a new design or flavor.
  2. I want to sell it, or at minimum, be set up to sell it.
  3. I want it to be something that people want.
  4. I want it to be something that multiplies my efforts once designed.

There’s some other touchy-feely sort of things that I don’t really have words for. One thing that would satisfy this requirement is to make a kit. First I was thinking of making travel ukulele kits, but the design I started down proved to be a bit too difficult and needs some refinement. That project isn’t dead, but it is on the shelf for now.

The other idea I had from the start was a DJ midi controller. I considered making it a USB midi controller, but after discovering the ESP32 (or really, just convincing myself to take the plunge) I think I’ve decided on a Bluetooth Low-Energy controller.

I did some initial research; and for some of the touchy feely reasons, I’ve decided to go with the esp-idf sdk over an Arduino stack. There’s some good technical reason for this too, but it is mostly that I want to get closer to the hardware, and while Arduino is great, it isn’t very mature for the chip.

I also found out that the ADC on the ESP32 isn’t the highest quality. I’m only processing human input, so it probably would be just fine, but I took the opportunity to also grab a few dedicated ADC chips while ordering some ESP32-WROOM modules. I designed a little breakout board for those ADC chips and sent it off to seeed studio and should get those back soon. They were FAR smaller than I thought they would be, so this should let me try my hand at SMD soldering as well as give me something to do prototyping with.

For a prototyping board, I’ve picked up the ESP32 Thing board form Sparkfun. This has been a joy so far, but compared to the reference board, it threw me when it had a 26mhz clock rather than a 40mhz.

Now that I’ve got a dev board and my toolchain compiled, I’ve gone ahead and played with a bunch of examples in the esp-idf repository. All but one compile and flash out the gate, and it appears that the one closest to what I want to achieve works well (though I’d need either a phone/computer side app or a second ESP32 dev board to test it).

I’m now diving into the BLE MIDI spec. These two links should prove useful for anyone else diving into similar stuff:

This weekend I was thinking about my design. I want to make this into a kit for DJs, but I also want it so sound mixers can use it for software audio levels. The input controls are a bit different between the uses, but very similar, and all the supporting hardware is the same. Instead of making two kits, I’m thinking I’ll have a layout on the board that is a bit modular so you can solder in either linear sliders, fade pots, or buttons. It won’t be entirely modular due to physical and input constraints, but I’ll try to make it so you can build a variety of configurations. I haven’t exactly figured out how, but I’m also considering adding if possible some way to auto-detect which parts are populated to auto-configure your device.

My plan is to design the circuit board in Eagle and use the Fusion360 sync to provide holdouts for an enclosure. This will allow people who buy the kit to design their own enclosure. Part of this came from a desire to have a mid-century modern inspired DJ controller, but it seems like the perfect way to allow anyone to make whatever enclosure out of whatever material(s) they want.

This is more of a brain dump of a bunch of ideas and progress since I didn’t think to start this earlier, but I look forward to keeping everyone updated with progress here.

I welcome comments along the way, and I hope this post serves as use for others. I’m sure I’ll make mistakes along the way and hope to share those too.


This is my breakout board for the ADC, I forgot to add that to the first post, I’ll add a photo once I have the physical part. I hope I did it right :).


Well, tonight has been pretty successful. After finding the Gatts Table Create Demo, things went pretty quickly.

I got the Service and Characteristics matching the spec first (not sure on value, but the UUIDs are right).

Then I got advertising correct. After some research, I had too large of a payload since the UUID is 128 bits, so I had to remove signal strength and then advertising started showing the primary service.

I can see the device showing up in Garage band, but for some reason it doesn’t show up in the Midi devices panel, but I’m not sure if it is supposed to show up here. I can connect, I get a packet from the app.

Next I need to start implementing the service protocol now that the advertising is working.


After a couple days of banging my head against the wall, it works! I was referencing just the wrong memory for the send command, I also made use of @lukecyca’s awesome debounce library providing a queue of debounced button presses:

Here’s me showing that it works (I threw the battery on there to show there’s no trickery through cables).

My circuit board for the ADC should arrive on Tuesday, and I’ll need to now get out the old breadboard to start roughing out a circuit. This is exciting!


I got back into the circuit design and have done my layout. The layout allows for either a column of buttons, or a linear slider with a fader slider at the top.

All controls are optional, so as a kit builder you’ll be able to have only the buttons/sliders you want.

Additionally, I’ve added LEDs for each of the switches, so you’ll be able to optionally illuminate them. I’m probably over-doing it by intending to use a variant of the 596. Driving a single low current LED is probably plenty done by a 595. I’ll end up ordering these and doing a prototype first just to make sure.

After talking to one of my friends that I am targeting this for, I also replaced one column of buttons with additional fader pots. This is a happy coincidence in that it makes it so I don’t have to use any special boot GPIO pins. All the pins I’m using should be ‘safe’. I wanted to avoid multiplexing so that I can get proper external interrupts on the buttons for minimal latency. The ADC I’m using had just enough pins. In fact, now that I’m writing this, I could re-use the conflicting linear slider analog input and have one left over.

There’s still a few more signal lines to hook up, and I noticed that the 596 does not have an Output Enable pin on the diagram (probably why my first circuit board forgot those, gah!).

Here’s what I’ve got so far:

Also, I haven’t figured out power (that’s likely the empty space) but for the first version, I might do my own first pass at duplicating a known circuit, but put it behind jumper pins so I can optionally just use a power module off the shelf.


I’ve been putting a lot of time into this one. Probably more than I should :-/.

Over the weekend, DHL delivered my breakout board for my ADC chip. It is quite small, so I’m hoping this doesn’t prove too difficult to solder. If it does, I’ll have to scrap that chip and go for something a bit larger.

Once I get this chip on a breakout board, I can validate that it works how I expect it, I’ll write the firmware to validate my assumptions. Hopefully there isn’t much to debug on this side of things.

After looking up how much it would cost to print this PCB, I’ve decided to scale it down a bit. If I could assume I was right I wouldn’t feel too bad with the prices I was seeing, but given I don’t know how this will work, I’d like something that I can grow into. Scaling it down means removing some buttons, which is also good because I need a few GPIO pins back for ICSP and some SDI chip select. i’ve decided to remove a row and a couple faders. This still gives me up to 5 channels of mixing; 4 of them with fade, or 4 channels, all with fade and 3 extra fade (plus a bunch of other possible combos). Removing one of the fade over the columns let me put the ESP32 into the board a bit more, and removing a column let me get the full width down to 100mm and the height is now 100mm. While this will be a smallish control panel, nothing says you can’t have several of them. Being under 100x100 means I can print them at seeedstudio for quite cheap.

After lamenting over what I’ll do for power, I realized that the sparkfun board I have is exactly what I want. I can plug in USB, run from lipo, charge the lipo battery, and run from the lipo. Also, sparkfun is open-source and they use Eagle, so i grabbed the Eagle .sch file. They break out the functions quite nicely so it was just a paste in. Board layout wasn’t nearly as easy.

I still have a few signals to wire up for SPI, but this is the board layout as-is.

I’ll need to spend a bit more time doing some hand-layout of the power components and beefing up the traces.


Work has continued for several days trying to clean up things, readjusting layouts, checking connections and pins, etc.

I got some great help on the circuit board design slack channel with regard to layout. I’ve taken many of these suggestions and incorporated them into my board, specifically for the power circuit.

Since I intentionally have some physical separation between the power/battery circuit and the signal area, I also drew a holdout area to keep the autorouter from draping a signal trace across my power lines.

Next I’ve built out power lines that go directly to my ESP32 power filter caps. I don’t know if this is necessary but my idea here is that hopefully I can achieve the cleanest rails by having large traces direct to these caps.

Also, to help isolation, I’m doing a GND fill on both top and bottom layers.

I’ve also simplified it a bit further. While I’d like LEDs, it adds another 1/3rd the number of elements to solder, causes me to have surface mount parts on the back side (shift registers) and quite frankly, complicates things for my first board. I’m leaving the solder pads in there in case I want to have the odd LED under a button hand-wired up to something, but it is a feature that I’ll leave for the future.

Maybe I’ll play with having the signal connection also drive the LED rather than them be microcontroller processed. That would make them simply light up when activated which would still give good feedback. By removing the second SPI device, it frees up a bunch of GPIO that can now be ‘safe’ GPIO pins (ie; not a lot of functionality conflict depending on what is happening, ie boot.

Here’s a look at the full board

And here’s a closeup of what I’ve done with the power section. It allows for USB in, to charge a lipo battery, and to operate on either the lipo or usb. It is literally a copy of ESP32 Thing by sparkfun

I also massively cleaned up my schematic because that was getting hard to read:

Things left to do:
Check all my connections
Finish wiring off my SPI lines from my ESP32 to my ADC
Add an override in case the power circuit doesn’t work
Make a protoboard mockup of my ADC to see if that works as I expect it to.
Check all my connections again
Add some silkscreen art
Check a third time.
Do a final check with the community (make sure I’m not crazy)
Send it off.
Hope it works.


So the ADC didn’t work out like I hoped, and in reality, it is probably too small a trace for a kit.

So I’ve done some validation with the onboard ADC and it looks like it’ll work. The ADC onboard is a lot faster than the Atmel, so I’m not so worried about it anymore. It is also 12-bit and so even if I need to do some remapping I’ll have enough resolution to hit the MIDI output (I believe 7 bit if I recall correctly).

One downside is that top and bottom end of the ESP32 ADC has some dead spots. Beyond that it is a pretty linear response curve. If I can fit my signal into a .1v to .9v range I should get about full use of the potentiometer wipers. I can up with overly complicated resistor nets to solve this when really it was a much simpler problem
With some help of @lukecyca early on and @Jarrett coming in with correcting me I have a better simple solution for finding my range. I’ve implemented that in the design and I’m pretty happy with the board so far.

The last big things to verify is if my assumptions are right with hooking up UART and the multiplexer. The multiplexers seem pretty straightforward and I can manually hook up a chip for UART to match my design to make sure I can program one of these once assembled. If I can’t program the chip once assembled I’m pretty much doa unless I were to make a pre-programming board, but I want to allow for in-circuit programming.

If this ever goes full-on kit, I intend to make a preprogramming fixture so at least a base version can be installed.

I did a quick calculation on the number of possible layouts that can be achieved and it is over 12-million. But in reality there’s only a dozen or so that I expect to actually see built. But since I’m using cherry switches, I do expect people to get creative with different buttons (for instance, clicking buttons for some and soft for others.

I’m building out my parts list for mouser so I can send in an order for my initial trial boards. Once I validate the last two major unknowns that are work-stoppers if wrong, I’ll ship off a batch for test boards.

Then I’ll turn my attention to refining software.

This is getting exciting; but it has taken about 10x more time that. I initially expected.


I’ve exported my BOM and come up with suitable parts in Mouser’s project manager (just a glorified saved shopping card). I now have a rough idea what one of these will cost me; and it still is below most MIDI devices I see out there, so win so far.

I’m narrowing down real fast into my prototype 1. This is what it looks like so far:

Assuming this works, this is the spec:
Up to 5 channels of linear sliders
Up to 7 channels of faders
Up to 16 low-latency “note” buttons
USB Powered (micro USB, no I didn’t go for USB-C, but I did think about it, maybe a future version).
In-circuit programming
Supports charging 1 cell lipo battery
Runs off of 1 cell lipo battery (won’t be included in the kit, since the capacity vs physical space is more of a personal preference)
Also just added pinouts for all the LEDs under buttons so you can do extra stuff with them (maybe make a second board that does light patterns :smiley: Mostly I’m leaving that as an option to the user,

Some of the up to conflict with each other, here are a few sample layouts:

  1. 4 linear sliders, 4 “note” buttons, 4 faders (might be good for mixing, with a few effects)
  2. 5 linear sliders, 4 faders (might be good for just a pure mixing board with no effects)
  3. 2 linear sliders, 8 “note” buttons, 7 faders (might be good for a 2-up DJ setup)
  4. 16 “note” buttons, 1 slider, 4 faders (where you want to maximize effects or triggering, or even use with a keyboard HID firmware (say for trigging special keys, keyboard shortcuts, setting volume, etc).

I’m in the final stages of pre-order verification. I’m nudging things around to try to make them the best. I welcome any and all suggestions/concerns at this point.


I’ve further refined little bits here and there, mostly cosmetic (but one functional issue). There’s more bonus features I want to add and cosmetic cleanup, but they are all low risk.

I’ve shipped off prototype validation 1 (v0.1) to seeed studio. They have a $1/board deal for up to 100mm x 100mm for up to 3 boards. In total with shipping I’m in for a tad over 35 cad for 3 boards.

Because this is a kit, I’d like to eventually do a medium run at oshpark; as I hear the board quality is excellent.


Looks awesome! A few questions, I haven’t been paying close attention:

  1. presumably this needs a computer or other host device with built-in or dongle support for BLE? Is there a dawless use case? Maybe a sister device to “break out” the Bluetooth to old-fashioned circular MIDI?

  2. Can it run off USB when there’s no lipo connected?


Yeah, any computer with BLE (Bluetooth 4.0+) should support this. So far I’ve connected with my iOS device as well as my 10.13 Mac, but windows 10 supports BLE as well. Once connected it is just like USB midi.

A dongle to go from ble to USB/din would be cool, that might be a future project if this goes well.

Yes, no battery is actually required. The kit won’t come with a battery so by default it will be USB powered. You can plug/unplug at will and it shouldn’t turn off if you have a battery attached. I am trying to make it as flexible as I can since it is intended as a performance device.


Also, the LiPo/Charge/Supply circuit is directly taken from the ESP32 Thing board. One upside of open-source boards is that they solved it for me.

I’ll be interested to see how it goes over the long term, but that board has been doing well for me so far in testing.

I’ll be including their contribution in the distribution materials (as well as other contributors to the project).


I got my components in and printed out (on paper) my circuit while I wait. This gives me an idea of how everything will fit together.

I’ve set this up as a 2-up dj console with 2 sliders, 8 buttons, 4 top faders and 3 side faders (though i’d probably just omit two of the top faders if I were doing this as a 2-up)

It is tight, but I think it’ll work nicely. These are certainly smallish controllers, but I’m intending for them to be very portable; drop one in a bag and go.

I’ll start gauging interest on a large run once I have a final cost and once I’ve validated the design. I’ve already found a few cosmetic things that I’ve changed, but I’m tagging things in git so I know what I’ve sent.


I’m starting to get my 3d models into the design; these will be used in both enclosure generation as well as documentation images.

Here’s an early rendering.

Adding a GL orthographic render, I think I like this more:


This looks really professional!

I don’t claim to understand the use-case, but there something that came to my mind while admiring the rendering…

Those potentiometers or rotary encoders at the top are quite close together. If you haven’t already, I suggest checking that there is enough spacing for the knobs that go on to the shafts. I had to redo a front panel because of this once…

There is also a usability aspect of having knobs very close. In my last project, I glued all the knobs and buttons and stuff on a printout of the circuit board and played around with them to see how it will feel. I ended up spacing the rotating knobs further apart so that my fingers have space to go between. Really depends on how you plan to use it.

(If you haven’t gotten the knobs yet, 3D printing a rough approximation of their shape of them worked well for this purpose)



I’ll likely be turning my own knobs, but yes, they are tight but I’ve ensured clearance between each knob.

In reality, if I were making the above layout, I’d probably just omit the knobs above the buttons to give more room in-between the channel faders. They are potentiometers rather than encoders. I have ordered both center-detent and non-detent ones depending on how the user wants it.

The primary use is to use it as an input device for either DJing or mixing, but the flexibility of it is intended to support lots of layouts. For instance, if you just wanted a 16 button hotkey keyboard, this can function as that.

It is a small board for a couple reasons. Primarily, due to price. Once you go over 100mm x 100mm, the price goes up fast. The second reason is I want these to be very portable. If someone needs more buttons/sliders, there’s nothing saying they can’t run 2 of them (they could even put 2 in the same case).

You are right though, it can be cramped when you populate every piece in there.