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: Thu, 8 Jan 2004 20:55:20 -0500
Well looking closer I see:
passing a value of zero for the flags makes this call equivalent to
MusicSequenceLoadSMFData
which is a different function from MusicSequenceLoadSMF that I was
referring to - though I notice that the HTML document describes it as
behaving the same as MusicSequenceLoadSMF.
So perhaps a fix in the header comments is still needed?
Robert.
On Jan 8, 2004, at 8:47 PM, William Stewart wrote:
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.