I'm confused. I watched with interest the discussion about USBAudio MIDI over the last few weeks, because I had a client who needed some help. I now have his device in hand. This is basically a drum pad, with no external MIDI ports; it generates MIDI, and it accepts a limited number of MIDI control commands, all via USB. So, he set up his descriptors to have an embedded IN jack (connected to the bulk OUT pipe) and an embedded OUT jack (connected to the bulk IN pipe). This enumerated fine, but it didn't show up as a MIDI device. That is, midiInGetNumDevs was 0, and midiOutGetNumDevs was 1 (the default MIDI device). I could bring it up in graphedt and see two pins on the filter, but I couldn't connect them. Interestingly, if we plug this into a Mac, it is recognized and configured, and the Mac starts sending bulk reads. On a whim, I tried adding an external IN and external OUT jack to the descriptors, identical to the sample given in the USBAudio MIDI spec appendix B. Now, it DOES appear in midiInGetNumDevs and midiOutGetNumDevs. However, when I do midiInOpen and send some blank buffers, I never see any bulk reads from Windows. I tried running MaxMSP to read from the device, and I still never see any bulk IN reads. I've tried XP and Vista. What does it take to get convince USBAudio to start sending me bulk IN packets? (On a side note, I've been amused to see that almost everyone is propagating the same mistake from the descriptors in that appendix. The sample "Class-specific MS Interface Descriptor" in section B.4.2 has an element wTotalLength, which is supposed to be the length of itself plus all of the jack and element descriptors. For this example, that's 7+6+6+9+9, which would be 37, or hex 0x25. And yet almost everyone has 0x41 in that field, copied from the erroneous sample, regardless of how long their descriptors really are. They only way to get 0x41 is to include the endpoint descriptors, which is wrong. I assume USBAudio ignores this field.) -- Tim Roberts, timr@xxxxxxxxx Providenza & Boekelheide, Inc.