Jump to content

stever

Members
  • Posts

    28
  • Joined

  • Last visited

Everything posted by stever

  1. Thanks for the link! I can see why my quick addition of the AC descriptor failed... the interface numbering needs much more consideration than I gave it. I was about to dig back through the USB MIDI spec again, and look for the problem... you've made that exercise a lot simpler. As I feared...I've had a brief play with some of the software USB analysers, but didn't find them particularly useful - probably due to being new to USB, I guess. Hardware analysers are just too expensive for non-commercial use. At least you and others have pioneered the way and shared your findings, for which thanks again. Regards, Steve.
  2. The main interface will be normal MIDI, but I want to be able to loop through the computer very easily so that I can send Sysex and controller data (not realtime, usually) to the synth without messing with cables. On the topic of USB-MIDI, though I can see from the spec that timing isn't guaranteed, in practice I haven't seen much of an issue with it. I am using a pretty simple setup tho... Steve.
  3. Apologies up front for this long post. I give background to some questions I have, but for expediency, I've listed the questions at the start: 1) Why would a MIDI device enumerate correctly but not appear as a MIDI interface? 2) Is my understanding of running status for USB-MIDI correct? 3) Does anyone have good tips for developing descriptors? ========== I have a DB50XG daughter card that I plan to turn into a stand alone synth for my wind controller. Several designs exist already, and can be found on the web. However, I've decided that I also want to add USB connectivity so I've started researching what is required. I've done a lot (a lot!) of reading of USB specs and Microchip docs (I already have some PIC experience and Robert Lang's MIDINator showed that there's not too much needed to get something functional). Reading the MIDINator code raised some questions in my mind so I blew it into a PIC18F2550 and there were immediately some questions arising. The device enumerated OK and appeared as "USB Audio Device" in the device manager (WinXP) and its status said it was working correctly. However, no new MIDI interfaces were available. Digging around, I found references to a limit of 10 MIDI devices in the registry, but this didn't seem to be the problem as only 3 MIDI devices were shown there. I then tried the MIDINator on another computer and Bingo! it not only enumerated, but also showed up as a MIDI interface. I've yet to identify why I see different behaviour on these two computers. One thought I've had while writing this is that the system that doesn't "see" the MIDINator has MIDIOX and MIDIYoke on it (and a third-party USB MIDI interface)... I just tried removing all of these but the MIDINator still doesn't show up. I tried striking up a dialogue with Robert Lang, but he seems to have gone offline... His code credits this site so I came looking and found this rich resource! So thanks up front for setting this up. So my first question is: 1) Why would a MIDI device enumerate correctly but not appear as a MIDI interface? As far as USB-MIDI implementation is concerned, I had a question that I tried to get answered on the USB.ORG site: The 4-byte MIDI-USB packets always have a status byte - that is, there is no running status as far as USB-MIDI is concerned. This implies that for inbound MIDI streams I have to inject a status byte if the input MIDI controller uses running status. And, conversely, I'll have to remove status bytes when appropriate to use running status, and thus save MIDI bandwidth, on outbound MIDI streams. Presumably, on the host side, the MS MIDI drivers inject status bytes on outbound streams if the sequencer software uses running status and may (or may not, as the host has much more bandwidth than MIDI) remove appropriate status bytes on inbound streams. 2) Is my understanding of running status for USB-MIDI correct? Looking in more detail at the MIDINator code, which is largely based on Thorsten's code, I don't believe that the inbound MIDI stream is handled correctly if error sequences are received (although I haven't fully analysed it, so could be wrong). I'm planning a new finite state machine implementation to handle the conversion, including any error sequences. I think it may be simpler to understand as a consequence (for me at least!), but I'll found out when I start. One last question: I was working my way through the descriptors to figure out how they worked and found that two *mandatory* descriptors were not present in the MIDINator config descriptor (the Audio Control standard and class-specific descriptors). I then found Thorsten's comments in http://www.midibox.org/forum/index.php?topic=4070.0 that said he'd left them out because they caused a crash... this matched what I found when I added the descriptors back in and changed the bInterfaceNumber in the Standard MS Interface Descriptor to 1 as in the USB-MIDI spec. Changing bInterfaceNumber back to 0 stopped the crash, but now I get an Error 10 (unable to start the device) in device manager. I'm now at the point where I'm trying to develop my descriptors and debug is not simple! I was hoping that having a working device as a model would make it pretty easy, but this first problem just to meet the spec is frustrating. 3) Does anyone have good tips for devleoping descriptors? Enough for now! Thanks, Steve.
×
×
  • Create New...