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: Herbie Robinson <email@hidden>
- Date: Wed, 13 Feb 2002 01:00:43 -0500
On Tuesday, February 12, 2002, at 03:02 PM, Doug Wyatt wrote:
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.
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.
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.
I actually think it would be a good idea if a UUID got added, just to
avoid the once in a blue moon customer support call when there was a
conflict. I think it can be done in an upward compatible manner
(assuming that MIDI Services will always make sure there is one
associated with every object).
When the app quits, the source should basically be treated as a
piece of offline hardware.
That behavior should probably be optional, but seems like a good idea
(so that applications can be restarted in any order).
There should be an API to get a source from a unique ID, which will
return offline sources as well as online ones.
I concur.
Thoughts? I think doing things this way makes everything very clean
from the programmer's perspective, and it shouldn't be hard to
implement (in theory anyway.)
That still doesn't do away with a good reason to keep around the text
names, too. This is more of a future in that it doesn't make much
sense until there is a configuration editor, but that will happen
(hopefully soon). Consider the following scenario:
1. User with a large studio creates a studio setup document with say
12 MIDI devices in it.
2. User then works for 2.5 years and has 60 projects with literally
thousands of device selections on various MIDI tracks.
3. A device gets accidentally removed from the configuration.
4. Later when the mistake is realized, device gets recreated with
the same name, but a different Unique ID. Restoring the file is not
an option for the user community (hey, I don't even know where these
things are kept...); so, the original UID is lost.
5. If the application has also saved the text name, it can put up a
dialog noting that the configuration had changed and offering the
option of changing the selection, but offering the newly created
device with the same name as the default.
Consider another scenario with a changing device configuration.
1, 2. same
3. User buys a new synth and sells an older one.
4. The application can no longer find an appropriate device, but it
can display the old name in italics or some other special way to
remind the user what had been used before (which may not be at all
obvious from track names).
I have done both of the above and I can't tell you how delighted I
was that the OMS interface kept around the old name.
--
-*****************************************
**
http://www.curbside-recording.com/ **
******************************************
_______________________________________________
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.