On Aug 30, 2006, at 10:10 AM, David A. Hoatson wrote: When I try to receive SysEx messages they are either broken up into 3 or 4 byte packets (using a Roland UM1 and the Roland driver),
This is normal. The driver can split sysex messages across MIDI packets or packet lists, and your app needs to be prepared to handle it. You can't expect to always get a full sysex message all in one packet or packet list. Note that if a packet does contain any sysex (start, middle, or end), it won't contain any other MIDI data. or they don't come in at all (using a Firewire device based on the BridgeCo DM1500 and the standard Apple driver).
Obviously that's not normal. Sometimes the 3 or 4 byte packets seem to get 'stuck' in the MIDI driver as I'll see the first part of the SysEx message, then the rest of it doesn't come in until more bytes are written out. Not sure what you mean exactly here -- how long do they get stuck for? Who's doing the writing in this case? (You mean the input gets "stuck" until some MIDI output is sent out? To any device, or just the one you're reading from?)
I launched MIDIMonitor - and while MIDIMonitor is running (but not even displaying any info in the MIDIMonitor window) instantly my code starts receiving full MIDI SysEx message (not broken into 3 or 4 byte packets) and the Firewire I/F starts working perfectly.
What does "full" sysex message mean in this case -- how large are they? What happens if someone sends a really large sysex message (several hundred bytes or more), does the whole thing come in in one packet?
Also, do you see similar results when any other MIDI app is launched?
On Aug 30, 2006, at 12:33 PM, David A. Hoatson wrote: It look like MIDIMonitor does basically the same things I do. Of course it looks like he installed a MIDISpy which gets the MIDI bytes between the driver and the app... so I'm guessing that something is going on there.
It's possible the "spy" has something to do with it, but I'm kind of skeptical. It only operates on outgoing MIDI data (usually sent by applications), not on data that comes into the computer via other MIDI interfaces. If you're only reading input data and not writing, or MIDI Monitor isn't running, it shouldn't be doing anything at all. (What happens if you uncheck everything in the Sources section under "Spy on output to destinations"?)
It's also really strange that this failure case is backwards (fails when spying isn't happening, works when spying is happening).
But I'm usually wrong at least five times a day, so just in case, you might want to remove the "spy" driver (probably in ~/Library/Audio/MIDI Drivers/MIDI Monitor.plugin), quit all apps that use CoreMIDI (or maybe even restart), and try again. Note that MIDI Monitor will reinstall it when it launches.
Also make sure you don't have any other unnecessary or old MIDI drivers installed. They all run inside one process (the MIDIServer), so a single rogue driver can accidentally mess up other devices, even if its device isn't even plugged in. Do you have the latest version of the Roland driver?
Hope this helps, and sorry to give you more new questions than answers.
-- Kurt Revis |