Re: MIDIClientDispose and MIDIServer
Re: MIDIClientDispose and MIDIServer
- Subject: Re: MIDIClientDispose and MIDIServer
- From: Robert Grant <email@hidden>
- Date: Sat, 4 Dec 2004 11:36:52 -0500
Hi Pete,
How about forking a sub-proc from your startup item that does the MIDI
calls - then when the sub-proc quits the MIDI server will quit - if not
in use by another proc?
Robert.
On Dec 3, 2004, at 9:57 PM, Doug Wyatt wrote:
On Dec 3, 2004, at 18:04, Pete Gontier wrote:
Since MIDIClientCreate implicitly launches MIDIServer if necessary, I
assumed that the last client to be disposed via MIDIClientDispose
would
implicitly quit MIDIServer. This seems not to be the case. MIDIServer
only
quits when my app quits.
yeah, it quits when the last process which ever created a client quits.
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.
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?
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.
Ideas?
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.
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 ...
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'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. 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? :-/
Doug
_______________________________________________
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
_______________________________________________
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