• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: MIDI driver monitoring -- bad destination?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MIDI driver monitoring -- bad destination?


  • Subject: Re: MIDI driver monitoring -- bad destination?
  • From: Doug Wyatt <email@hidden>
  • Date: Wed, 13 Mar 2002 01:41:13 -0500

On Tuesday, March 12, 2002, at 02:43 , Kurt Revis wrote:
OK. Just to check: Am I safe in assuming that I can check the version of the CoreMIDIServer bundle, and if it is later than the version installed in 10.1.3, just go ahead and use the provided MIDIEndpointRef as-is?

Yes.

Like this:

CFBundleRef coreMIDIServerBundle;
UInt32 version;

mNeedsMonitorPointerWorkaround = false;

coreMIDIServerBundle = CFBundleGetBundleWithIdentifier(CFSTR("com.apple.audio.midi.CoreMIDIServer"
));
if (coreMIDIServerBundle) {
version = CFBundleGetVersionNumber(coreMIDIServerBundle);
if (version <= 0x15108000) // 15.1, the version as of 10.1.3

To be totally rigorous, test version against 0x1800800 instead 0x15108000.

mNeedsMonitorPointerWorkaround = true;
}

(and then use mNeedsMonitorPointerWorkaround as appropriate later on)

Or is it possible that the bundle's identifier could change in the future?

I see no good reason for it to ever change.

Alternatively, I could use CFMainBundle() from my driver, which returns the CoreMIDIServer bundle--but I am not sure that I should rely on that always staying the same.

I don't see a reason for that to change either.

Or would it be safer to call CFBundleCreate() with the path /System/Library/Frameworks/CoreMIDIServer.framework, since that should not change (since changing the framework's path would break anything linked against it)?

And that *really* can't change; seems safest.

And on top of all that, what you're doing is checking for the existence of a bug in frameworks that have shipped, so even if your code were to fail to be able to locate/open the bundle in a future version for some unforeseeable reason, you'd be doing the right thing by assuming that that newer version has the fix.

If CoreMIDI provided a version number in its API (like kCFCoreFoundationVersionNumber for CoreFoundation) then I wouldn't have to worry about all this bundle stuff. I've filed a feature request for that.

I think the bundle services are designed to do what you're asking for, so I don't think there's a reason for us to add API to return static data that has a documented way to get to it.

Doug

--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden http://www.sonosphere.com

"The most beautiful thing we can experience is the mysterious. It is the
source of all true art and all science. He to whom this emotion is a
stranger, who can no longer pause to wonder and stand rapt in awe, is
as good as dead: his eyes are closed."
--- Albert Einstein
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: MIDI driver monitoring -- bad destination? (From: Kurt Revis <email@hidden>)

  • Prev by Date: Re: Bit Width vs. Bit Depth
  • Next by Date: Dave
  • Previous by thread: Re: MIDI driver monitoring -- bad destination?
  • Next by thread: Anyone having success using MusicPlayer?
  • Index(es):
    • Date
    • Thread