• 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
MIDI source unique IDs (was Names for MIDI sources)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MIDI source unique IDs (was Names for MIDI sources)


  • Subject: MIDI source unique IDs (was Names for MIDI sources)
  • From: Doug Wyatt <email@hidden>
  • Date: Mon, 11 Feb 2002 23:02:16 -0500

On Monday, February 11, 2002, at 06:37 , Pete Yandell wrote:
On Tuesday, February 12, 2002, at 09:35 AM, Kurt Revis wrote:

Also, how can the app remember the user's choice for the next time the
app is run?

Get the integer property kMIDIPropertyUniqueID.

On the topic of unique IDs, how do unique IDs work with sources created with MIDICreateSource (or MIDICreateDestination for that matter)?

The IDs are mathematically generated from the name, but then altered in the event of a duplication, so they're only semi-predictable.

In particular, is it possible for me to set my app up so that I can create a MIDI source with the same unique ID each time I run it?

There may be a lack of security such that you can change a source's unique ID (and thus potentially make it non-unique), but now that I've mentioned that, I'm probably going to have to fix it!

That way other apps can use the unique ID of the source I create to save the connection to my application, just as they would use the unique ID of a real source to save the connection to that source.

In OMS the recommended practice was for apps to bind to both uniqueID's and names, so that you could tolerate either of them changing. In OMS (going from memory, not looking at the spec) I think you could provide a hint as to what you wanted your virtual node's uniqueID to be, but you wouldn't always get it -- there was the same potential for something else having come along and grabbed the same uniqueID.

This discussion is making me think we should just add a UUID property for nodes and be done with the problem that way.

And the other question: once I've got a stored unique ID, how do I find the source that matches? Do I simply iterate through all the sources looking for it, or is there a better way?

No better way (although see below).

One of the things I've noticed is that MIDIGetSource will return only presently connected sources, whereas iterating through devices, their entities and endpoints will also show previously connected devices that are currently offline. I'd like my app to be able to take a unique ID and find the source even if the source is offline (and mark it as such in the UI, leaving the user with the choice of reconnecting the source or choosing another), but iterating through every device, entity and endpoint seems a painful way to do this. Is there a better way?

This is intentional. The source and destination lists are filtered so that you only see what's currently online. The device/entity/endpoint tree is not filtered, so you get a complete picture.

You might find it useful to write a function to walk the device/entity/endpoint tree and apply a function pointer to every endpoint; at least that way you're only writing the painful code once.

Doug
_______________________________________________
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.

  • Follow-Ups:
    • Re: MIDI source unique IDs (was Names for MIDI sources)
      • From: Pete Yandell <email@hidden>
    • Re: MIDI source unique IDs (was Names for MIDI sources)
      • From: Kurt Revis <email@hidden>
  • Prev by Date: Re: ComponentRefcon
  • Next by Date: Re: Questions on data in MIDIPackets
  • Previous by thread: Re: ComponentRefcon
  • Next by thread: Re: MIDI source unique IDs (was Names for MIDI sources)
  • Index(es):
    • Date
    • Thread