USB-MIDI-Controller

ATmega32u4 (Arduino Leonardo) as host device
- Uses LUFA to send MIDI messages to the computer over the USB
- Uses I2C to talk to one or more clients
Some ATtiny as client device
- ADC to read the controller value from a potentiometer or similar
- Uses the USI as I2C to communicate with the master
- Possibly replace the ATtiny with some cheap ATmega or some other MCU with multi-master I2C, 1 at least 7-bit ADC, and a free GPIO pin to get around having to use USI :)
- Update: The USI is an ungodly mess. „Here's a shift register and half a counter, have fun.“ I've probably poured 15 hours of work into this, but I'm definitely switching. Probably to the cheapest ATmega I can find.
Clients are daisy-chainable, see Communication

Communication

The host device acts as a slave and has address 1, all clients are I2C masters
Initialization
1. When a client powers on, it repeatedly (until it receives an answer) sends a message to the host, consisting of
  - A request code
  - The number nc of controls it needs allocated to itself
2. The host then allocates a continuous block of nc controls for the device and responds with
  - The response code corresponding to the request
  - The 7-bit address of the first control
3. The device then enables the next device, either by pulling its RESET line high or enabling VCC
MIDI messages are constructed by the clients and sent as-is. The host will buffer them until it has received the STOP, then forward them over USB. As all MIDI commands start with a set bit, this is an easy way to separate management and MIDI messages.
- On collision, the device waits until a STOP condition has been detected and tries again.

A preliminary command table, with each length including the command byte

Request	Length	Response	Length	Description
0b00000000	2	0b00000001	3	Initialization
0b1xxxxxxx	According to the MIDI spec	None	0	MIDI message

Common wires include
- GND
- SDA
- SCL
Each device uses one pin to trigger a FET that connects its VCC to the VCC of the next client. Alternatively, it may connect to the RESET pin of the next client.
This uses four wires. A nice and simple method of connecting these would be to use 3.5mm TRRS connectors, like those commonly used for smartphone earphones that include a microphone. The variant where each client controls the next client's RESET pin could use 5-pin (mini-) DIN connectors.