Re: MIDIClientDispose and MIDIServer
Re: MIDIClientDispose and MIDIServer
- Subject: Re: MIDIClientDispose and MIDIServer
- From: Pete Gontier <email@hidden>
- Date: Mon, 06 Dec 2004 19:26:23 -0800
circa 12/6/04 12:21 PM, "Pete Gontier" <email@hidden> wrote:
>> I wonder how big a mess it would be to load your MIDI driver yourself and
>> pretend you're MIDIServer. You'd have to send some private messages to the
>> driver to give it some callback function pointers to use instead of calling
>> CoreMIDI APIs. You'd need to check whether MIDIServer were running first.
>> Just a thought experiment.
>>
> Yes, I have run that one myself a couple of times in the last few days. :-)
> The driver in question, however, is the Apple class driver. Baking that code
> into my helper app would defeat a lot of the purpose of having Apple maintain
> and release class driver binaries with the operating system. Plus it would
> bloat my helper app because the sample handles a more general case than I
> need.
>
> Another thought experiment I've been running involves my app-level MIDI
> abstraction layer, which makes it possible for me to write control panels for
> CoreMIDI, OMS, and FreeMIDI all at the same time (though I never got around to
> sub-classing for FreeMIDI). In theory, I could sub-class this layer and
> implement just enough of the class specification to get by for just this one
> device. That would still be effort on the order of writing a plug-in from
> scratch, though, and I'd still be giving up many of the benefits of having
> Apple maintain and release class driver binaries with the operating system.
Thinking more on this, the situation is even bleaker. Let's assume the
helper app converses with the device according to the class specification
but not through CoreMIDI. This means there is a collision at the USB level,
since only one client can have the USB interface at a time. The practical
effect is that the helper app can't talk to the device if a MIDI app has
been launched and MIDI apps can't see the device while the helper app is
talking to it and some, perhaps many, will not recover even after the helper
app is done even if the driver does. This leaves me with two options:
-- Implement a driver which talks to the helper app instead of USB.
-- Implement something in the helper app akin to Classic-style
arbitration under the assumption that Apple's class driver also
does.
-- Have the helper app do something tricky with virtual endpoints
in response to a message sent from a driver which does nothing
but inform the helper app.
All of this sounds sketchy and complicated. :-(
--
Pete Gontier
http://www.m-audio.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