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.
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:
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!