I got my USB MIDI interface running. It's build upon an ATMega16, powered from USB through 2 diodes (3.5 volts). I have potentiometers (AVCC/AGND) connected to the analog inputs (PORTA) which are converted to a range from 0x00..0x7F to create up to eight midi controls (CC). On my STK500 I've also tested a simple key routine (PORTB), which sends eight "white" keys (60, 62, 64, 65, 67, 69, 71, 72). Serial debugging is enabled.This interface shows up on my linux PC and works fine with vanilla kernel >= 2.6.23.x or with a little patch for my 2.6.22.1-rt9. To get the first key press sent after power up I defined USB_INITIAL_DATATOKEN to USBPID_DATA1.MIDI messages are also received from PC but for now only a LED is toggled (and a debug message sent to UART).This device is class compliant, therefore I use device type audio/midi stream. This doesn't go with an obdev USBID - so I used a LabOnly VOTI ID (16C0/03E8). I would like to public my source code (with USBIDs commented out) but doesn't want to have a clash with the obdev license. It would be nice if christian or someone else could give some directions how to do.

I got my USB MIDI interface running. It's build upon an ATMega16, powered from USB through 2 diodes (3.5 volts). I have potentiometers (AVCC/AGND) connected to the analog inputs (PORTA) which are converted to a range from 0x00..0x7F to create up to eight midi controls (CC). On my STK500 I've also tested a simple key routine (PORTB), which sends eight "white" keys (60, 62, 64, 65, 67, 69, 71, 72). Serial debugging is enabled.This interface shows up on my linux PC and works fine with vanilla kernel >= 2.6.23.x or with a little patch for my 2.6.22.1-rt9. To get the first key press sent after power up I defined USB_INITIAL_DATATOKEN to USBPID_DATA1.

butrus.butrus wrote:Could You tell us, what is the kernel patch used for?

The patches below (extracted from kernel version 2.6.24.3) do this bulk->int change and let the kernel recognize low-speed midi devices, the old 2.6.22.1-rt9 kernel said: "unknown device speed".
If you're using a new kernel >=2.6.23 there is no need for this patch. But I use the older 2.6.22.1-rt9 kernel because it works much better with my old laptop and jack, with newer ones I get xruns.
The patch consists of two parts: one for /usr/src/linux/drivers/usb/core/config.c:

This is awesome, it only took me a few hours to get it working on an Atmega8515 running at 16MHz. Thank you!

I was hoping to find that I could use this standard interface for output to my device from MAX/MSP at a rate higher than regular MIDI, but it seems that the maximum transfer rate is on the order of a regular MIDI interface ~1ms/command. Do you know what might be responsible for this limitation? I have a few ideas but haven't explored them all...
*timing from the OS due to the USB-MIDI specification
*timing from MAX due to the midiin/midiout objects
*AVR CPU usage limitations
*something to do with the poll rate
*low-speed USB bandwidth/packet-header limitations
*USB packet-size limitations due to the AVR's buffer size...?

Do you know what's responsible for bandwidth-throttling on USB (i.e. if this were a USB-UART adapter, somehow the adapter would have to tell the PC when its buffer was full... I assume similar would be true for a MIDI interface, unless all buffering/timing is handled on the PC...)

the slow transfer rate comes from the usb standard. A low-speed device has no bulk transfer - it uses interrupt transfer at a rate of maximal 1000 messages/s. The midi protocol puts 1 or 2 midi commands (4 byte) into one message (8 byte) -> voilà! I hacked this project and it worked for my needs. It's suited for standard applications like cc or some notes pressed by a human.
One of the usb gurus here will probably explain the timing much more detailed, maybe we get a nice solution. I think that dedicated usb chips will bring a speedup for you - or you switch to something completely different like OSC.

me again I've digged in the foum and found this thread:
http://forums.obdev.at/viewtopic.php?t=1030about bulk/interrupt and timing.
Funny, usb interrupt is not really interrupt. For my understanding interrupt has something to do with a door bell rung by a visitor and the usb spec behaves like someone who opens the door every minute to see if there's someone standing outside.

USB is a host driven bus. Every activity must be initiated by the host. This gives ugly semantics for things like interrupts but makes the bus logic (and thus the controller chips) much simpler (= cheaper).

after some problems viewing your pics I found them - nice pice of hardware. How do you connect the 28 pots to the AVR - do you use a mux?

That's what my project is intended for - letting musicians create their own midi gadgets.
Do you know the pepper project?
http://web.me.com/kuwatay/morecat_lab./ ... idi-e.htmlThis guy uses AVR-MIDI for driving his Gakken SX-150 synth - a fascinating little toy. He states that it works flawlessly with OSX and Win XP.

Another similiar gadget is the Monome http://monome.org/ - Franq from Barcelona gave me this hint - thank you.

Currently I'm very busy so AVR-MIDI is on "hold" for some weeks but I'm very interested in your success - good luck!