mlundinse
Member
Hi all
I would like to change the USB-Serial that is standard protocol for the USB port
into USB-MIDI. Has anyone worked on this ?
Once the descriptor stuff is done, the actual communication protocol should be similar to virtual serial port but sending and receiving 32 bit Midi messages. It doesnt need any line handling stuff and I can live without the remote reset code.
I am prepared to do the work, but would like to know if any work has already been done.
Regards
Magnus
http://www.suspectdevices.com/blahg/proposals/lets-get-loaded-a-midi-sysex-ecosystem-for-loading-and-debugging-code/
Also be careful with the current version of arduino midi which is GPL3 (no worthwhile features just incompatible with the maple licensing and not usable in commercial designs)
If you bother to port it (its not really that much of a library and I would do it differently (of course I feel that way about most of the platform :) )) then make sure you use the version that came with arduino 0022 which is not so restricted.
mlundinse
Member
My plan is to first write and test the low level USB stuff so the device connects and identifies as a USB MIDI class device. This will be based on the existing libmaple/usb_cdcacm.c and will make it possible to send and receive 4byte/32bit USB MIDI messages without doing any interpretation of them as MIDI data.
On top of this we can then easily build a MIDI object that understands MIDI data and uses the low level usb_midi instead of a standard serial port. Porting the Arduino MIDI like this should be easy, or a clean implementation can be. I will have a look at the interface to some existing MIDI libraries.
mlundinse
Member
I got a first version that seems to work ok.
Its wasteful by sending 4 byte USB packages, but most MIDI is not so high bandwith, so its ok for now.
Some discussion at http://arttools.blogspot.se/2013/04/midi-usb-class-for-maple-board.html
code at https://github.com/mlu/maple-ide
Regards
Magnus
I am looking at the changes you made to the ide (which are subtle at best). I cant figure out why we cant work with the makefile and libmaple as apposed to packing around and re building the whole gawdaweful mess. I will try to do that this afternoon. Excited to flesh out the rest of this.
IF you want the kludgeyness to go away the first things you need to do are to get your device to interpret a little sysex.
In particular the device should respond to the universal sysex for identity request and response. Then you can implement a device specific request like the GS reset described here. http://www.2writers.com/eddie/TutSysEx.htm .
mlundinse
Member
Hi Don
I work with Fedora 18 in a VirtualBox on an IMac.
Why this mad setup ? I used to do all development under Linux, and feel at home there,
but for several reasons I switched my main 'normal' work to an iMac. So all my historical dev stuff is made for Linux.
The only change to the IDE is really the ArmCompiler file, but in order to use it the
new version of the flattened libmaple file system must be used, and I also use a more modern arm-gcc toolchain. The script in libmaple that is supposed to copy files from libmaple into Maple IDE seems broken from newer changes to libmaple. I have submitted my changes to bnewbold for review, but they are quite busy atm.
I see a few layers in the MIDI stuff:
*) MIDI-USB messages ( 4 byte/32 bit )
*) transfroming this to normal serial MIDI bytestream
*) Interpreting MIDI commands, like sys-ex
The only part I have worked on so far is the 4 byte usb-midi messages for not on/off.
I have a test sketch that echoes USB MIDI messages back to the host.
The main use is to send USB MIDI note on with an OpenPipe hooked up to the Maple
---------------
#include <wirish/usb_midi.h>
#define ledpiny 3
void setup() {
pinMode(ledpiny, OUTPUT);
MidiUSB.begin();
}
void loop() {
digitalWrite(ledpiny, MidiUSB.isConnected() );
while (MidiUSB.available()>=4)
{
unsigned char midibuf[4];
MidiUSB.read(midibuf,4);
MidiUSB.write(midibuf,4);
}
}--------------------
Regards
Magnus
I have a version of your library that works with libmaple and am working with it.
There are a couple of approaches that can be taken here with the usb midi which unlike usb_serial is packet oriented and not byte oriented.
1. Parse out the sysex that is intended for the target.
2. Deal with the midi events (except for sysex this is 1 event per packet)
3. Serialize and deserialize the data which you want to pass along to the uarts.
#1 should be done by the rx callback so that you can do things like identify and reboot the device programmatically.
I think it makes more sense (with a 32 bit processor) to keep the midi events in the same format as the usb in most cases.
I am also unconvinced that midi should have anything to do with print.
mlundinse
Member
The remains of the serial print class in usb_midi.cpp should of course be removed and there should only be read and write of 32 bit usb midi packages.
Then we could then add some convenience functions to interpret and convert the usb_midi packages to and from regular midi byte stream.
Sysex handling can be harder to do generally since there is no predetermined size of a sysex message, but we could add a state that tells if we are inside a sysex and a funtion that reads from the sysex in that case. Havent yet considered any precise details
/Magnus
Of course I didn't actually say WHICH day :) https://github.com/feurig/libmaplemidi
You must log in to post.