|
Kurt,
I was hoping you were listening... :-)
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.
I agree. This is completely normal and my
code handles this situation.
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'm not sure either. I see half the message come in my
ReadProc, then my code times out waiting for the other half (actually waiting
for the F7), and closes down the source (after writing an Abort SysEx message to
the device). At that point I see the other half of the message come into
my ReadProc. I can set the timeout to any value (I have done 12 seconds),
and the F7 never comes until I close down the source.
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 one
packet?
The SysEx messages coming from the device can be anywhere from 10
bytes to 320 bytes long. The longest message in this test is 155 bytes and
it all comes in one packet if MIDIMonitor is running, and multiple 3 - 4 byte
packets if not (or not at all in the case of the 1394 device).
Also, do you see similar results when any other MIDI app is
launched?
Good call! I didn't think of that. I launched DP4.5 and
it did the same thing as MIDIMonitor. Just having the app open changed how
the whole MIDI subsystem worked (or didn't, as the case may be). Man, I
must be missing something pretty basic here. Something else I need to do
to make sure the MIDIServer is fully running?
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"?)
Right - I tried unchecking everything and it didn't change the
behavior. When MIDIMonitor is just launched (not even looking at any
streams) my app works correctly.
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.
The MIDI Monitor.plugin wasn't there on my system. I did
remove all of the drivers that were there except the Roland driver, restarted,
and that didn't change the situation.
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?
Yes, I just downloaded the latest driver from Roland's
website.
Hope this helps, and sorry to give you more new questions than
answers.
It actually gives me hope! I'm happy to answer any questions
as long as I can figure this out and hopefully let everyone else know what dumb
mistake I made so they don't have to...
If find Apple's documentation pretty slim in content. A one
line description of a function with no example code seems a bit weak to
me. Since I'm a C/C++ kernel mode programmer, examples in Objective-C and
Cocoa don't help me much (other than knowing I'm making the same MIDI system
calls as the example). I laughed when I saw Echo.cpp was the only example
code.
Just to give more info: I am sending my SysEx messages to the
destination with MIDISend() instead of MIDISendSysEx(). Seemed like to me
that shouldn't matter - and I do see that my messages do get transmitted just
fine.
I'm really just guessing at what might be going on, so any help that you
can give is much appreciated.
Thank you,
David A. Hoatson
|