How to do USB MIDI? - Page 1
Forum section: electronics / general

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 11, 2015, 08:32:34 am
content: I am making a MIDI Router/Mapper that has the physical Din5 MIDI sockets. I would also like to add USB support -in that when I plug the USB into a PC, the PC recognizes my device as a MIDI in/out port.My MIDI Router is basically a bunch of MIDI sockets with the opto-coupler on the input and some open-collector buffers on the output.The brains is a ATmega1284 running at 20MHz (for now) with 2 physical Usarts and enough memory to do some programming. A 2x24 LCD display and a couple of buttons.I have no idea how that would work. Can I make use of standard MIDI drivers on the PC (which ones)? What do I have to program into my device? Do I need some USB chip to make this happen?This is a recent photo where I was testing the Usart/MIDI implementation with the display.As you can see, it's all in the prototyping phase still... Oh and the thing plugged in the USB if my laptop is the ICSP programmer...EDIT: It would be awesome if I could piggybag a 'normal' serial protocol over the same USB connection in order to program the device from the PC (have to write an editor for it then of course).Any suggestions would be most welcome.

author: andersm
author_rank: Super Contributor
timestamp: October 11, 2015, 10:27:07 am
content: The easiest way would be to present each jack separately to the PC, and let the user sort the routing in their DAW or a patch bay tool (which might be preferable, one less thing to configure).If at all possible, make it USB MIDI class-compliant. Custom drivers is a hassle both to make and use, but you definitely need a microcontroller with USB capability. If you want to stick with AVRs, I believe the LUFA framework comes with several USB MIDI examples.

author: old gregg
author_rank: Regular Contributor
timestamp: October 11, 2015, 03:40:27 pm
content: I've always wonder what that midi-usb was sending. Is it sending only the raw midi data at the MIDI rate (31250 baud) or is it also sending the USB frame to contained the data ?

author: andersm
author_rank: Super Contributor
timestamp: October 11, 2015, 04:41:57 pm
content: The MIDI data is encoded into 32 bits. The first byte consists of a "cable number" and a code number representing the message. The remaining three bytes are used to store the MIDI message as it would be sent over normal serial MIDI. The 31250bps data rate does not apply at all, the limits are the same as for any USB bulk data endpoints.You can download theUSB MIDI device specificationfor free for the full details.

author: old gregg
author_rank: Regular Contributor
timestamp: October 11, 2015, 04:46:33 pm
content: I have the usb protocol pdf but I haven't browse into it yet. I'm wainting for a projet to do so.So basically the midi data is encapsulated in the USB one. I was hoping for something simpler

author: electr_peter
author_rank: Unknown
timestamp: October 11, 2015, 07:12:17 pm
content: One solution is to take MIDI to USB converter (with separate MIDI in and MIDI out ports) and connect to your device via actual MIDI port. These are available for a low price.Other solutions would be to either mess with USB-MIDI support on MCU side or find a ready made chip which does USB-MIDI conversion for you.

author: ehughes
author_rank: Frequent Contributor
timestamp: October 11, 2015, 11:21:30 pm
content: Get a teensy 3.2. There is a nice driver to get started.

author: JTR
author_rank: Regular Contributor
timestamp: October 12, 2015, 03:50:25 am
content: Quote from: old gregg on October 11, 2015, 04:46:33 pmActually, it probably is not as hard as you think. You do not need to become expert in the USB side of things. As others have pointed out there are numerous ready rolled USB-MIDI bridges for PIC, AVR and ARM that do the heavy lifting with the USB side of things. All you need to do is send packets with 4-bytes of data per MIDI event. Really, it's just a API call. While I am not a AVR / ARM user I do like the work of Paul Stoffregen and one of his AVR based Teensy boards would be a good start.

author: miguelvp
author_rank: Super Contributor
timestamp: October 12, 2015, 04:14:38 am
content: the PSoC 5LP has USB-MIDI support among other USB functionality on their Full USB implementation.http://www.cypress.com/file/132756/download$10 prototyping board with programmer built in:http://www.cypress.com/documentation/development-kitsboards/cy8ckit-059-psoc-5lp-prototyping-kit

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 12, 2015, 05:20:25 am
content: Wow, great response guys thanks.AVR is what I know and I have considerable time invested in writing software for it (although most of that should be reusable on any platform),so I was not planning on switching MCUs or switch to teensy's.And yes, I want to keep this (CLASS?) compatible with current standards. I want the user to be able to plugin an play (Win&Mac).So I browsed through the specs and it doesn't look that complex.But that LUFA framework looks (from a distance) to be perfect for the job. Have to take a closer look.So I need to sort out the hardware: another MCU with on-board USB, perhaps a very small MCU that just does USB -offloads the main MCU niceley, or a USB-MIDI chip - haven't seen those before but I'll have a look around.Okay, the back spot is slowly filling in...

author: nctnico
author_rank: Super Contributor
timestamp: October 12, 2015, 06:37:40 am
content: Don't use 2 microcontrollers! Gettting them to work together can become very hard very quick! The best thing to do is to use one microcontroller with built-in USB and implement the MIDI CDC class plus you user application.

author: andersm
author_rank: Super Contributor
timestamp: October 12, 2015, 06:58:43 am
content: Quote from: old gregg on October 11, 2015, 04:46:33 pmJust sending the raw MIDI data would mean you'd need as many USB endpoints as you have jacks, each with their own buffer memory etc. With the "virtual cables" each endpoint can support up to 16 jacks, which in turn means you can use a much cheaper controller in the device.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 12, 2015, 07:56:33 am
content: Quote from: nctnico on October 12, 2015, 06:37:40 amReally? I have never done this but I would think that it would not be any different from using other 'devices' that have on-board MCUs. Just have an interface (I2C/SPI/USART) and a protocol (which I would have to design but would be very simple and basic) ... ? I must be missing something..?The reason I consider the option of two MCUs is that I can have one that is geared towards running the main program (lots of flash and RAM and Usarts) and one specialized in handling USB which would only need to run the USB specific code and some extra for the internal protocol... (I haven't done a product search yet - its all theory)Of course I want to keep the price down. Not in a 'lets get rid of this decouple cap' way but if I can choose a cheaper chip I will consider it of course.

author: Scrts
author_rank: Frequent Contributor
timestamp: October 12, 2015, 08:19:10 am
content: Have a look here:http://ucapps.de/

author: nctnico
author_rank: Super Contributor
timestamp: October 12, 2015, 11:01:39 am
content: Quote from: obiwanjacobi on October 12, 2015, 07:56:33 amIt means you need to cut your program in half. Each part needs to communicate over that interface. Think about what happens if something is wrong with the USB / MIDI interface. That is where things get hairy.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 12, 2015, 03:51:40 pm
content: Quote from: nctnico on October 12, 2015, 11:01:39 amWhat is hairy about that? The USB-MCU should send (report in some way) that the connection was lost or whatever is appropriate. Off-loading something like USB communication from the main core still looks like a benefit to me - something less to worry about...?The core of my program is not about USB details. It is about detecting and transforming MIDI messages. So I don't see how I'd cut my program in half...Then again, I might just not get what you're trying to say...

author: nctnico
author_rank: Super Contributor
timestamp: October 12, 2015, 05:07:53 pm
content: Having two microcontrollers doing one job is like having 2 people working on the same job. It needs a lot of management overhead!

author: andersm
author_rank: Super Contributor
timestamp: October 12, 2015, 07:04:48 pm
content: Twice the firmware updates, twice the fun.

author: obiwanjacobi
author_rank: Super Contributor
timestamp: October 13, 2015, 05:05:50 am
content: Quote from: andersm on October 12, 2015, 07:04:48 pmRight - good one.