Re: MIDIClientDispose and MIDIServer
Re: MIDIClientDispose and MIDIServer
- Subject: Re: MIDIClientDispose and MIDIServer
- From: Pete Gontier <email@hidden>
- Date: Mon, 06 Dec 2004 10:55:22 -0800
circa 12/3/04 6:57 PM, "Doug Wyatt" <email@hidden> wrote:
> At one point it probably crossed my mind to shutdown the server when
> the last MIDIClient was disposed, but then I considered a client which
> is living in a plugin or something like that. That plugin might come
> and go fairly frequently, creating and destroying clients, and would in
> turn cause the server to get launched and quit frequently. Since
> launching the server takes a noticeable amount of time on all but the
> fastest machines with a minimal set of drivers installed, that was
> probably the end of that.
Right. I had all those thoughts and already wrote code to defer
MIDIClientDispose until I hadn't needed the client for a few seconds.
>> This is problematic, since, when deployed, my app won't ever quit. (It's a
>> startup item.) It's bad enough my app will be hanging around all the time,
>> and I don't want to be responsible for keeping MIDIServer also hanging around
>> all the time. Unfortunately, it no longer seems there is a way to avoid
>> this...
>>
> um, was there ever one?
I didn't mean some software feature went away. I only meant my assumption
has been show faulty.
>> ...short of writing a separate app which I can quit whenever I want to enable
>> MIDIServer to quit. But that's going to be work for which I do not have time.
> I could conjure up a property, that when set on a client, would tell the
> server to quit if no other clients remain when it is disposed. That would be
> the most elegant solution IMO, but it would require Tiger.
Right, and that might help, but not for Panther.
> You could explicitly kill the MIDIServer when your startup item is done with
> it, but I imagine that cure could be worse than the disease -- someone else
> may have already started using the server ...
Right. That's why I was hoping MIDIClientDispose did it implicitly.
> So I take it you just need to make CoreMIDI calls for a little while from your
> startup item, then stop and go into a state where you're not going to need it
> any more? Or do you need CoreMIDI at irregular intervals?
I have ten zillion entry points. I am a helper app for a USB device with a
control panel. The device is configured via MIDI messages. It needs to be
configured each time it is plugged in. It needs to be configured each time a
user logs in. It needs to be configured when the user diddles the control
panel. I'm probably forgetting one or two of the cases as I write this
email.
> I'm afraid that to be any more helpful I'd have to understand why it's not
> practical to divide your app up into multiple processes.
It's technically possible. It's just not friendly to my schedule.
> One idea is to look into using the mach_init mechanism; your main startup item
> could be a shell that sends a mach message to launch the process that actually
> does work. That's actually fairly simple and reliable, assuming the code is
> amenable to being divided that way. Or is the code which decides when to do
> work substantial and intricately linked to the code that does work? :-/
Right now it is. Separating them would be work for which I don't have time.
--
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