Re: audio file bug in AudioUnitHosting
Re: audio file bug in AudioUnitHosting
- Subject: Re: audio file bug in AudioUnitHosting
- From: Robert Grant <email@hidden>
- Date: Sun, 4 Jan 2004 12:05:53 -0500
What bugs me about this is the fact that there are so many different
ways to identify files in Mac OS X that the number of APIs one needs to
keep up on just to do work is pretty crazy - and it looks like Apple is
having a hard time keeping it straight too!
Here's an example that caused me to scratch my head recently: The
AudioFile API uses FSRef to identify files, but right next door the
MusicPlayer API uses FSSpec to identify files for SMF loading/saving.
(And arbitrarily uses FSRef when loading a MIDI file with flags). Why
the two different methods?
It seems that Apple should identify the preferred API for working with
files and identify when using the alternatives is called for. Rather
than just (what seems to be) capriciously using whatever is familiar to
the developer that's working on that part of the API (or example code).
Thanks and a Happy New Year to everyone too :-),
Robert.
On Jan 4, 2004, at 12:46 PM, Marc Poirier wrote:
On Sun, 4 Jan 2004, David Duncan wrote:
Unfortunately after looking at this, I think the problem runs deeper
than that. For one reason or another, they choose to store the paths
as
CFStrings, but initially encode them as MacRoman and no longer than
512
characters. So even with the changes you previously sent, you will
still have badly encoded paths in some cases.
Eek, you're right, that's pretty weird/bad. I didn't look into it that
far.
Basically a complete fix would likely involve replacing CFStringRefs
with CFURLRefs throughout AudioFileChooser.cpp where appropriate, and
changing SelectedFile() to take a CFURLRef instead.
Or perhaps better (and simpler) would be to store them as FSRefs.
After
all, that's what you the code already starts with in
CAFileChooser::SimpleReceiveDrag(), and then it gets converted
(unsuccessfully) back to an FSRef later on when it actually needs to be
used, so it seems silly to not just keep it as an FSRef all the time
(and
FSRefs don't have the maximum path length limitations that CFURLRefs
unfortunately have).
Marc
_______________________________________________
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.
_______________________________________________
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.