Re: USB MIDI sample driver
Re: USB MIDI sample driver
- Subject: Re: USB MIDI sample driver
- From: Herbie Robinson <email@hidden>
- Date: Sun, 06 May 2007 17:32:34 -0400
At 5:02 PM +0100 5/1/07, Nuno Santos wrote:
I want to adapt the sample MIDI USB driver to make a driver for a
custom MIDI controller device.
It look to the operating system as a HID device.
Right now i have acomplished the objective of reading from the
device using HID manager.
I've been looking to SampleUSBMIDIDriver code and it seems that it
receives a handle to a USBDevice:
bool SampleUSBMIDIDriver::MatchDevice( USBDevice *
inUSBDevice) {
Can i change the argument type of the driver constructor and
functions to HidDevice?
It's probably more complicated than simply changing the names. There
are probably differences in the HID device interface and the USB
device interface beyond simple name changes. Both are USB based; so,
they will probably be pretty close. For example, I haven't looked at
the sample driver for several years, but I think that MatchDevice was
not part of the base class and therefore can be changed all around to
suit your needs.
Will it then be called when it supposed to?
The callbacks defined by the base class for the MIDI driver
(MIDIDriverClass.h) will continue to happen.
I would like to have more information on how Mac OSX calls the
drivers to understand what i have to do.
The client side MIDI API starts the MIDIServer process. The MIDI
Server loads and initializes all drivers. The drivers are
implemented using the CFPlugin interface in MIDIDriver.cpp. The
CFPlugin interface vector for MIDI drivers is called
MIDIDriverInterface (in MIDIDriver.h). The documentation for all the
callbacks is in that header file.
If you weren't planning on using C++ for your MIDI driver,
MIDIDrvier.cpp would be the only part of the sample driver that would
be relevant to you. If you are planning on using C++ (recommended),
then the base class in MIDIDriverClass.h will define all the
callbacks into your driver. MIDIDriver.cpp is the glue that turns
the C base CFPlugin interface into a C++ base class. Note: I am not
looking at the latest version of the sample driver. I hope it hasn't
changed too much. Everything else in the sample driver is your
sandbox. Do you you need to do to support the device you are working
with. A lot of the existing code should be very usable, but you will
need to understand how IOKit works in order to modify it. There is a
lot of stuff to learn.
The MIDI server process inherits that client's standard output; so,
you can do printfs and see them in the debugger console log. Be
forewarned that you can't do printfs from the I/O callbacks because
they happen on real-time threads and doing printfs will mess things
up royally. For that matter, you can't do anything else that's bad
for real-time threads from the I/O callbacks either. All of the
other callbacks happen as part of a single normal priority thread. I
never tried this, but you can supposedly point the debugger at the
MIDIServer program file and get the Xcode debugger to start it
(useful for debugging your initialization code). The MIDIServer
program is buried in one of the MIDI frameworks in
/system/library/frameworks. I don't remember the name offhand, but
it should be obvious if you go looking. If an application is already
running, you can attach to the MIDIServer by process ID from gdb.
On other debug thing to be aware of. Buggy drivers can occasionally
hang the MIDIServer and prevent it from terminating properly. When
this happens, the system will not start another process and all MIDI
applications hang as soon as they try to initialize. This doesn't
happen much on a production system, but it happens quite a bit when
you are debugging. The cure is to kill the MIDIServer process.
I would recommend debugging the configuration part of your code in a
standalone application (just make a shell program that allocates a
MIDIDriverClass and calls the start callback. You may have to stub
out the call to create new MIDI devices, because I may only work if
you are running in the MIDIServer. The alternative is to get the
Xcode debugger to start the MIDI server.
Can anyone give me a lights on this or point me to usefull
documentation about this particular issue?
I don't think there is much driver specific documentation beyond the
sample driver and the headers. The MIDI client API documentation
does document the calls that are to be used by the driver. Given how
much better the online documentation is, these days, I would say the
best bet is to start with MIDIDriver.h and use Xcode to look up the
documentation on the calls it makes.
--
-*****************************************
** http://www.curbside-recording.com/ **
******************************************
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden