The idea of giving vendors hooks into the class driver at certain
points, especially after a device is identified, has been kicked
around. It might look like another kind of driver plugin that the
class driver loads. Would you use such hooks if they existed?
It would be nice to have an API such that a driver could effectively
subclass and optionally call "super" down to the MIDI class driver.
Can I even do that as an
application as opposed to a driver plug-in?
Yes. Most of what AMS does can be done by any application that wants
to, and more -- AMS protects certain propeties that are supposed to
only be set by the driver, but that's not enforced by the server. I'd
discourage people from going too deeply into this (e.g. playing around
with connections) but in the case of a hardware utility that wants to
slam its own icon onto a driver, that's a perfectly good reason. Just
set the property on the device.
I've written a healthy framework around CoreMIDI which is compatible
with Cocoa bindings, and a standalone DMX-MIDI driver and tool. MacFOH
also has an editor which duplicates and extends AMS functionality, and
both work well together. One API that I found to be missing from
CoreMIDI was a function to return a new 32-bit unique ID. What's the
recommended method for generating these, other than brute force?
--
Shaun Wexler
MacFOH http://www.macfoh.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden
This email sent to email@hidden
