Re: audio file bug in AudioUnitHosting
Re: audio file bug in AudioUnitHosting
- Subject: Re: audio file bug in AudioUnitHosting
- From: William Stewart <email@hidden>
- Date: Thu, 8 Jan 2004 17:47:50 -0800
Well, look closer (we've tried to fix this):
first the original one that is superseded by the later one (a flag of
zero is the same behaviour as the original call)
// MusicSequenceLoadSMF() also intelligently parses an RMID file to
extract SMF part
extern OSStatus MusicSequenceLoadSMF( MusicSequence inSequence,
const FSSpec *inFileSpec );
// passing a value of zero for the flags makes this call equivalent to
MusicSequenceLoadSMFData
// a paramErr is returned if the sequence has ANY data in it and the
flags value is != 0
// This will create a sequence with the first tracks containing MIDI
Channel data
// IF the MIDI file had Meta events or SysEx data, then the last track
in the sequence
// will contain that data.
extern OSStatus MusicSequenceLoadSMFWithFlags
(MusicSequence inSequence,
FSRef *inFileRef,
MusicSequenceLoadFlags inFlags );
On 04/01/2004, at 9:05 AM, Robert Grant wrote:
>
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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.