Gentlemen, I believe we've got ourselves a new driver!
It turns out the problem I was having earlier where MIDI events didn't arrive, was a pilot error (reloading the wrong module). With my latest patch, both MIDI input and output works. I'll send it in a separate email for review.
Thanks a lot to Daniel and Clemens! Your help was a invaluable!
One caveat I have discovered with the patch: If you keep the instrument plugged in, but reload the driver, then the driver gets out of sync with the MIDI messages and won't report any. This seems to be because, in the stream, the message type is cached and subsequent messages do not report what type of message they are unless they are switching to a new type (going from control message to note message, for example). You can reset the stream by manually generating MIDI messages of different types (turn the volume knob while pressing a few notes), or eventually the instrument will reset itself and send the type anyway. So it's not critical, but would be nice to fix. I'm not sure how to solve it though...
On 08/24/11 21:51, Clemens Ladisch wrote:
/* reset the port */err = snd_usbmidi_ftdi_command(umidi, 0, 0);if (err < 0)break;/* set mctrl */err = snd_usbmidi_ftdi_command(umidi, 1, 0x303);if (err < 0)break;The chip reads its initial configuration from the EEPROM, so these commands might not be necessary.
You're right, they're not.
/* set baud rate */err = snd_usbmidi_ftdi_command(umidi, 3, 0xc04e);Replace 0xc04e with 0x60 to get exactly 31250 baud.
That did the trick! Thanks!
Furthermore, the FT232RL chip sends two modem status bytes in its packets, so we need something like this to prevent them from being interpreted as MIDI:
Done!