Re: MIDI source unique IDs (was Names for MIDI sources)
Re: MIDI source unique IDs (was Names for MIDI sources)
- Subject: Re: MIDI source unique IDs (was Names for MIDI sources)
- From: Doug Wyatt <email@hidden>
- Date: Sun, 17 Feb 2002 20:50:19 -0500
On Tuesday, February 12, 2002, at 06:12 , Pete Yandell wrote:
Well, the OMS way doesn't sound very nice. Putting the onus on apps to
try matching on two methods is asking for trouble, not to mention
duplicating code.
Herbie Robinson explained why you need to use both -- if the object
vanishes, it's very useful to the user if you still know its name. But
make the uniqueID the primary binding; it allows for objects to be
renamed.
UUIDs would solve the problem quite nicely, but it seems overkill. And
given that there is already the unique ID interface I would think it
made more sense to simply make this work properly than implement an
entirely new interface.
You're right. The catch is the 1/32767 probability (or greater
depending on the quirks of my ID-generator function) is that two virtual
nodes will end up with colliding uniqueID's, if they were created
separately at times when the other didn't exist, then are both
instantiated at the same time.
I could reduce that probability by another 2^(-16) by failing to mask
uniqueID's to 16 bits (I once had a fantasy about making it easy for
someone to implement OMS on top of CoreMIDI).
So, here's my humble opinion on how it should work:
When an app first creates a source, that source should get a system
allocated unique ID. (Apparently this is supposed to happen, but the
current version of CoreMIDI has a bug.)
The app can save that unique ID and, when restarted, request that
unique ID back again. The current method of setting the unique ID of
the source after creating works fine for this.
I think that might be okay, though I might still write-protect that
property from clients other than the one that created it. And of
course, there would have to be validation of the uniqueID.
When the app quits, the source should basically be treated as a piece
of offline hardware.
I don't think I like the idea of offline virtual endpoints hanging
around; for one, there would be no way to enumerate them since the API
contract is that offline endpoints are not enumerable except by
iterating through the device/entity tree, and virtual endpoints don't
have devices.
Will have to think about this more, especially with regard to softsynths.
There should be an API to get a source from a unique ID, which will
return offline sources as well as online ones. That way an app that
saves a unique ID for a source that goes offline can still get
properties for that source (the name in particular) and can flag it is
offline in the UI rather than treating it as entirely nonexistent.
I do agree that it would be useful to have a set of API's to look up
objects by their uniqueIDs (driver-owned devices, external devices,
entities, sources, and destinations all have them...).
Now a question: do offline devices hang around in the device tree
forever, get reset on reboots, timeout after a certain time...?
They hang around until a hypothetical studio setup editor deletes
them -- IMHO the system shouldn't be presuming to be able to tell the
difference between a device that is powered off vs. a device that the
user borrowed and will never see again. I think there are some comments
about this in the docs in MIDIDriver.h and MIDISetup.h.
Doug
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
"It's kind of fun to do the impossible."
-- Walt Disney
_______________________________________________
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.