This project is submitted for

Description

This is a MIDI/OSC instrument which interprets values read from sensors with a microcontroller and emits MIDI and OSC messages based on some very configurable logic. While this functionality is not particularly novel, it rarely exists in a wearable, stage ready form factor. I like the form factor of a guitar because it can look quite traditional in a rock band context, but upon closer inspection is clearly not. This reflects my taste in music, superficially recognizable, but substantially deviant.

Details

The goal of this project is pretty simple; Take the general functionality of your typical MIDI keyboard or control surface and implement it (robustly, and with low latency) in the form factor of a guitar. The motivation is a a little less straightforward. Three things:

I wanted to wear it on stage while maintaining the freedom to move about.

I wanted to make it myself.

It didn't want to spend a fortune.

I like the form factor of a guitar because it can look quite traditional in a rock band context, but upon closer inspection is clearly not. This reflects my taste in music, superficially recognizable, but substantially deviant. While I can play the guitar, I didn't feel it necessary that a functional guitar be augmented with MIDI controller capabilities, unless the two can be seamlessly combined. This is primarily because my single-threaded brain just cannot effectively handle playing an instrument well, while controlling other parameters.

Because a guitar hangs down in front of you, facing out, visual controls and feedback are pretty useless. A touch screen on the front of the guitar for example, is effectively a touch-pad for the player and a light show for the audience. Therefore I am mostly interested in tactile type sensors which can be blindly interacted with.

The DIY approach is simply an excuse to get lost in the details of interesting technical challenges instead of practicing, or composing actual music.

Regarding limiting cost... Yeah, anyone who has ever attempted a DIY project like this knows it's actually BS. There is no competing with the economies of scale that a market product has. We DIYers like to trick ourselves by spreading the costs into tiny chunks, over many months. But, I consider the premium an investment in enjoyment and the knowledge gained along the way. So that's how it ended up here.

The Build

The guitar used was a junk no-name electric. I hollowed out from the front of the body with an oscillating multi-tool and a wood blade, leaving space for the FSRs. Because the body is plywood, it was pretty easy to remove the bulk of the material. I spray-painted everything black and carpeted the inside with adhesive Velcro strips (loop side). This has been quite helpful for cable management and general experimentation. Just put some hook Velcro to the bottom of a breadboard and stick it in there. Need a USB Hub? Raspberry Pi? Velcro!

The FSRs are attached with some double sided foam tape which holds them solidly in place and gives them a little bit of padding, which is good when you are banging on them with your knuckles. The little thumb joystick is mounted in the body with hot glue, and wired through a hole bored into the body cavity. The joystick is meant to be moved with the palm of your hand, allowing you to modulate parameters while tapping on the FSRs... In practice, little thumb joysticks like that are junk, they have too little travel to introduce any decent dynamic. I am actively looking for an alternative, larger joystick with more travel.

The first prototype was done using breadboards and an Arduino Mega2650 clone. When it was finally functional, I found the latency to be unacceptable, the breadboard connections were fragile and problematic,and I also found it lacking interface components. So, I swapped the Mega2650 for a Teensy 3.6, soldered all the connections using some protoboard, and added the four faders plus four LED buttons. The result is this new prototype module. I'm designing a PCB which will replace this.

There are USB-A and RJ-45 jacks to the side using some nice, locking Neutrik jacks. Because the Teensy's advanced USB capabilities, there is only USB IO at the moment. The unused RJ-45 is for some future ideas.

There is an SSD1306 64x32 OLED display mounted to the side of the body of the guitar. I simply flattened a little part of the edge with a belt sander, and drilled a hole into...

Project Logs

Well, I couldn't find enough time to make a demo video before the prize deadline, although it's not nearly finished, I'd have liked to show at least what works. But so it goes with side projects. Maybe I'll get to it this week.

Looking forward, I'll be ordering some body v1 PCBs soon. They always take a couple of weeks to arrive, so in the mean time, I'm going to focus my attention on the firmware again.

In particular, I need to get the I2C communication with the head module going again. I had it working with the i2c_tc library, but that lib does not play nice with the Audio library. Since I'd like other people to be able to use this firmware, I'd like to avoid build system hacks and library patching. Therefore I decided to use the default Wire library instead. Unfortunately I implemented heavily on the non Wire compatible features of the i2c_t3 library so porting it requires some refactoring. Switching to the default Wire lib will likely help with the search for a new display library. Moving away from SPI means the current TeensyView lib is no longer an option, and it's likely that a replacement will expect the standard Arduino Wire interface.

I also think it might be a good idea to re-visit component sourcing. In particular, the guitar parts themselves. It's difficult to provide clear build instructions without a BOM. I'd love to find a good cheap source for unfinished body and neck parts that don't require having a CNC (or professional woodworking skills). I've also been experimenting with the viability Velostat FSRs beneath wood veneer, which opens some new design possibilities. More on this later.

The Teensy 3.6 is hooked up mainly with the edge pins, and a couple of the inner through-hole pins. None of the inner pads are connected.

Passives are 0805 which I find are pretty easy to solder by hand. I put the resistors on the bottom of the board as it is more likely that their values be swapped. Once the female headers for the Teensy are in place, the caps on the top of the board will be hard to get to.

I decided to go with header pins for the sensor connections. These could be male if you have a dupont crimper tool and you want to make ribbon cables to each sensor, or female if you want to just stick some hook up wire in.

I left space for the Teensy Audio Board to sit piggyback on the Teensy 3.6. This will require some stackable headers to make happen, but they are cheap.

I also decided to leave the ESP32 off board. I find the dev board is a little to big, and a module like the WROOM-32 requires a bit more to hook up.

I'd like to miniaturize the whole thing combining a SGTL5000 with a WROOM-32 in a package small enough to fit in the standard electronics cutout of those cheap Fender strat clones. It would make integration in a functioning guitar easier if the board was only modestly bigger than the Teensy itself.

I need to tweak a few things and finish fixing the few remaining DRC errors, but this board is almost done.

So, I got a chance to get started on the body PCB. Here is the current schematic:

It re-arranges a number of the signals compared to how they are currently hooked up in the prototype, but since the goal is a PCB anyhow, I'm being liberal with the changes. At the moment it is simply the Teensy 3.6 broken out with some simple signal conditioning.

I2S

The Audio library for the Teensy is far too cool to exclude from this project, and there are still resources available for audio processing. USB audio was my initial choice for this, especially because it completely avoids the complexities/pitfalls of mixed signal circuitry, but it turns out using more than one USB audio interface on a PC is a world of frustration. So, I decided to go ahead and try getting analog audio in/out via a codec (Likely a Teensy Audio Board) and I2S.

ESP32

I made an executive decision to abandon my dreams of using an Ethernet link for OSC messages, in favor of WiFi and/or Bluetooth via an ESP32. This decision was mainly driven by the I2S support. I2S requires a significant number of the signals broken out on the Teensy, The WIZ850io module (There is no native UDP/IP stack for the Teensy) is connected via SPI - optimally one with a FIFO, which would require two more unfortunately placed signals than an ESP32 connected via UART.

My experience with ESP32s has showed me that they cause a lot of noise on any shared power rails. It may be prudent to verify this, and how it affects the rest of the components, especially the analog signals.

SSD1306 - I2C vs SPI

I2S is also forcing me to evaluate my decision to use SPI for the little OLED display, and to try I2C instead. With SPI, the display refresh routine introduces very little latency to the main loop. It would be a pity if a switch to I2C introduced noticeable latency. I'll evaluate this soon.

PCB Design - TODOs

There are a couple of things I need to verify before I continue to the PCB layout.

Form Factor - Determine the size and shape constraints for this board

IO - Determine what type of connectors are best for this board

Audio - Determine if a PCB layout would be better including space for a Teensy Audio Board, or if it should just piggyback on the Teensy 3.6

ESP32 - Determine if a PCB layout would be better including space for an ESP32 module or even a dev board

Power - Determine what power supply, and conditioning measures will be necessary, especially if the ESP32 is on board

I'm sure there will be more points to address as I progress with the concept development.

I've been working on this thing for a long time now. It has seen a couple of iterations, and the edges are still really rough. There are a lot of unfinished bits, dead-end ideas, un-commented code etc. My hope with publishing this publicly is to clean up these loose ends. Any interest in the project will likely help motivate me to move forward on it. Here is a non-exhaustive list of things that need to be done:

Design a PCB for the body

Fix broken I²C communication between body and head

Implement the missing parts OSC GUI parameter config

Implement the OSC GUI preset copy/rename/save functions

Implement a useful MIDI emitter for the accelerometer data

Design some 3d printable protective parts for the exposed bits.

Provide better descriptions, code comments, build docs, pics, etc.

Features

Aside from fixing the boring details and broken things, there is a number of potential features that would be much more interesting to develop. Here are a few ideas I've been batting around:

Synth!

The Teensy 3.6 is laughing at the current workload. There is plenty of capacity to implement a digital synth, and the Teensy Audio library is amazing. I've already started this, but ran into a couple of problems:

An I²S codec needs quite a few pins, many of which are currently being used

USB audio is not really an option if you already have a USB audio interface.

Nothing insurmountable, I'd like to make this happen if I find the time.

Ethernet (or WiFi)

At the moment OSC is provided over SLIP encoded Serial. This works, but is a kludge requiring a bridge program to get the UDP packets that all the OSC clients expect.

There is a Neutrik RJ-45 jack built into the body of the ruitar, I could provide power over the unused pairs assuming 100-BASE-T. But without the USB cable I would loose all the USB* devices the Teensy can emulate, which would be a bummer.

Alternatively I could send the SLIP serial to an ESP32 and broadcast the OSC packets via WiFi, not sure about the latency though.

Membrane Potentiometer Alternatives

The kxmx_ruitar is really hard to play. Tracking on the "strings" is not bad, but the lack of any tactile feedback along them makes it difficult to get a position reference. Anyway, since MIDI notes are discrete, all the position data the pot and ADC could provide gets quantized to the configured 20 note range anyway... They might as well be buttons, right?

If anyone has any questions, critique, ideas, whatever... I'd love to hear it!