USB-MIDI newbie... questions!

[stever]

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.

[Ashiman]

USB is ridicoulusly bad for anything realtime audio related. No way around it ?

[TK.]

1) Why would a MIDI device enumerate correctly but not appear as a MIDI interface?

Some users of MBHP_USB and MBHP_USB_PIC interface have reported this issue in the past - it is related to the definition of the AC (Audio Control) interface. It seems, that this causes a problem with some Windows installations. I haven't started some more investigations, but just provide an alternative firmware without the AC definitions (see http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip, usbdsc.c)

Note that my descriptors could be slightly different from the ones used in the MIDINator firmware (I haven't compared them)

2) Is my understanding of running status for USB-MIDI correct?

Yes, absolutely.

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.

Could you please try if my own PIC based implementation works better with your host?

Note that it requires the USB bootloader, which is provided by Microchip (it simplifies the firmware upload). Therefore my firmware begins at 0x800.

3) Does anyone have good tips for devleoping descriptors?

Beside of try&error: not really. :-/

Best Regards, Thorsten.

[stever]

USB is ridicoulusly bad for anything realtime audio related. No way around it ?

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.

[stever]

I haven't started some more investigations, but just provide an alternative firmware without the AC definitions (see http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip, usbdsc.c)

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.

Beside of try&error: not really. :-/

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.

[stever]

Could you please try if my own PIC based implementation works better with your host?

Note that it requires the USB bootloader, which is provided by Microchip (it simplifies the firmware upload). Therefore my firmware begins at 0x800.

Can't promise that I'll be able to get to this soon - this is a spare time project and I don't have a lot of that, but I will take a close look at your descriptors to begin with and see what, if any, difference they make and report back. If I'm still having problems, I'll certainly take a look at your whole code package, though I've not been using  a bootloader so far so not sure what, if any, impact that will have.

Regards, Steve.

[stever]

....but I will take a close look at your descriptors to begin with and see what, if any, difference they make and report back.....

Well, after fixing up the interface numbering, I got a successful enumeration with the AC descriptors in the config, but there was no change to the situation regarding the availability of the new MIDI interface. On one machine, it failed to appear (the machine I need it on, of course), and on the other system it appears fine and MIDI packets could be directed through the interface.

I guess I'm going to have to try to hunt down the reason why, and I know it's not going to be simple based on the initial attempts I made and the comments from Thorsten here.

Anyway, thanks for the descriptor info... it made that part of the process much quicker.

Regards, Steve.

[TK.]

Hi Steve,

please keep me informed about the progress

Best Regards, Thorsten.

[stryd_one]

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.

You can't be trying very hard ;)

[stever]

You can't be trying very hard ;)

While I'm sure that it's possible to provoke severe timing discrepancies, and I've seen occasional problems when asking the computer to do a lot of other things at the same time, I haven't had too many issues when "single-tasking", just using a sequencer to drive a synth. It'll be interesting to see how things work out when I loop my wind controller through it  ???.  Though my main use will be for loading patches for the wind controller to use directly, so timing won't be a real issue anyway.

Steve.

[stever]

please keep me informed about the progress

Incredibly, and without too much effort, I now have my device successfully recognised on the computer that enumerated it but didn't show a new MIDI port. Here's what I believe did it:

I downloaded USBDeview from http://www.nirsoft.net/utils/usb_devices_view.html. This displays all USB devices that have been plugged into the computer, whether or not they are currently connected. The Options menu also lets you show Devices without Drivers. On my machine, there were three "Unknown devices" in this category. I deleted them and the entries for my own device.

After this, everything worked as expected... I hope this helps someone else.

Regards, Steve.

[stryd_one]

I haven't had too many issues when "single-tasking", just using a sequencer to drive a synth.

That's USB-MIDI's way of telling you that your music is not complex enough ;) I would just about guarantee that a wind controller will hammer it, with all the CC/RPN data they can push, but the way you're using it (direct to the synth) should bypass that anyway :)

[TK.]

Hi Steve,

thanks for this useful tip! :)

Would it be possible to get a copy of your firmware (binary is sufficient) - as I wrote in this posting http://www.midibox.org/forum/index.php?topic=10447.msg79114#msg79114 I noticed a new issue - three different firmwares are failing under Mac OS. The strange thing: the Cypress based MBHP_USB firmware is running fine, so that a Mac specific driver issue can be excluded.

Best Regards, Thorsten.

[stever]

Would it be possible to get a copy of your firmware (binary is sufficient) - as I wrote in this posting http://www.midibox.org/forum/index.php?topic=10447.msg79114#msg79114 I noticed a new issue - three different firmwares are failing under Mac OS. The strange thing: the Cypress based MBHP_USB firmware is running fine, so that a Mac specific driver issue can be excluded.

Hi Thorsten,

Happy to let you have the binary or the source I've been working with if you think it will be of help... it's basically the MIDINator code, fixed up to compile under C18 and configs tweaked to use an external 4MHz xtal instead of 20MHz. I've added in the Audio Control section of the config descriptors, too.

I've noticed some anomalies with it, that I believe are in the original MIDINator, but I'm still investigating this... for example, in debug mode (data going to RS232 instead of MIDI), a whole bunch of zeros are being sent as well as the MIDI data... these are not the spurious zeros you have seen from the UART, as far as I can see, rather that the code seems to interpret the whole 64-byte EP1out buffer, not just the MIDI packets. In MIDI mode, it looks like the midi_out routine doesn't pass these through, so you'll only see it in debug mode, but the data is being passed on by the EP1Get routine, nonetheless.

I've yet to work out why this should be; one thing I've noticed is that the Microchip firmware uses the bytecount field after returning the buffer back to the SIE, which doesn't seem right. As mentioned earlier, I don't have much time at the moment, so it may be a while before I get to the bottom of it.

I'm probably going to use the newer C18 firmware framework for my own code, rather than the one MIDINator uses... it seems to be better structured and also supports the USB bootloader function which I may use.

Let me know if you want the code, and the best way to send it to you.

Cheers, Steve.

[TK.]

Hi Steve,

if your variant still doesn't differ so much from the MIDINator code, it doesn't make much sense to test it on my site yet. I guess that it will also fail under MacOS. My own (assembly-based) firmware is mainly based on the Microchip framework as well, the class handler is completely rewritten (however, nothing spectacular) therefore the bytecount is read before releasing the semaphore to SIE.

Last saturday I incorporated all the framework errata which are documented here http://forum.microchip.com/tm.aspx?m=275422, but they don't solve the problem. I also found a bug in my own code (risk that wrong byte counter used in the OUT ringbuffer), unfortunately it wasn't related to the issue.

I feel that I'm not able to continue debugging without a hardware based USB analyser. But they are too expensive, especially for a sparetime project.

For next weekend I'm planning to write down all the findings, put the documentation and unstable firmware on the website, and to freeze the project again - in the hope that sooner or later somebody else will find the bug, or can give me a fully working firmware for further analysation.

Best Regards, Thorsten.

[stever]

Last saturday I incorporated all the framework errata which are documented here http://forum.microchip.com/tm.aspx?m=275422

Thanks for the link... some useful stuff there. I'd already got the errata, but the user input is great.

Are you aware of anyone trying the firmware from Embedded Inc. mentioned in that thread?

I feel that I'm not able to continue debugging without a hardware based USB analyser. But they are too expensive, especially for a sparetime project.

Yowch! Tell me about it... I started out as a hardware guy, and that was one of the first things I investigated.

For next weekend I'm planning to write down all the findings, put the documentation and unstable firmware on the website, and to freeze the project again - in the hope that sooner or later somebody else will find the bug, or can give me a fully working firmware for further analysation.

That would be really useful - I'll look out for it.

On the topic of errata, my 2550s all seem to have a revision code of 00000b... I think they must be very early parts (either that, or I'm reading the bits wrong, but I am seeing the correct device ID, so I think not). I've certainly had them for quite a while.

If I make progress to the point where I think you might find the code of interest, I'll let you know.

Regards, Steve.

[TK.]

Are you aware of anyone trying the firmware from Embedded Inc. mentioned in that thread?

No - I'm working on USB devices maybe one week per year and therefore don't follow the progress.

On the topic of errata, my 2550s all seem to have a revision code of 00000b... I think they must be very early parts (either that, or I'm reading the bits wrong, but I am seeing the correct device ID, so I think not). I've certainly had them for quite a while.

Which ID is printed on the package?

E.g., my non-working (EUSART bug) rev2. has 0504409, the working rev5 has 07351KG

I guess that the first four digits stand for year and calendar week of production.

I've released the source code + some documentation now:

-> http://www.ucapps.de/mbhp_usb_pic.html

Best Regards, Thorsten.

[stever]

Which ID is printed on the package?

E.g., my non-working (EUSART bug) rev2. has 0504409, the working rev5 has 07351KG

I guess that the first four digits stand for year and calendar week of production.

Uh-oh... my 2550s have 0522 as their date code... I've got some new ones on order, I hope they'll be more recent!!

I've released the source code + some documentation now:

-> http://www.ucapps.de/mbhp_usb_pic.html

Great... thanks for that... for now, however, I'm going to stick with the new Microchip framework, but if I decide to switch to asm I'll certainly take a look.

Steve.