Upcoming changes to AU API
Upcoming changes to AU API
- Subject: Upcoming changes to AU API
- From: Bill Stewart <email@hidden>
- Date: Tue, 08 Oct 2002 18:11:37 -0700
There's been a few emails about things we are working on, some of which
involve API changes, so I thought I should summarize these.
(1) MusicalTime
// outDeltaSampleOffsetToNextBeat - will contain the number
// of samples until the next beat
// from the start sample of the current rendering buffer
// outTimeSig_Numerator - the number of beats of the denominator value
// that contained in the current measure
// outTimeSig_Denominator - music notational conventions
// (4 is a quarter note, 8 an eigth note, etc)
// outCurrentMeasureDownBeat - the beat that corresponds to
// the downbeat (first beat) of the current measure
typedef OSStatus (*HostCallback_GetMusicalTimeLocation) (
void *inHostUserData,
UInt32 *outDeltaSampleOffsetToNextBeat,
Float32 *outTimeSig_Numerator,
UInt32 *outTimeSig_Denominator,
Float64 *outCurrentMeasureDownBeat);
This then changes the following struct:
typedef struct HostCallbackInfo {
void * hostUserData;
HostCallback_GetBeatAndTempo beatAndTempoProc;
HostCallback_GetMusicalTimeLocation musicalTimeLocationProc;
} HostCallbackInfo;
We had had some to and fro about adding a flags field for a reposition
operation amongst others, but we now believe that this is not required - the
AU can determine where it is from this and other information provided by the
original callback (which provides current beat and tempo)...
This mechanism will have some limitations - the callback cannot signify a
changing tempo that occurs within a buffer being rendered for instance. A
host can ameliorate this somewhat by using smaller buffers when dealing with
an AU that will use this information (this is analogous to the k-rate - and
many hosts will workaround this granularity problem by slicing up the
buffers into smaller ones when dealing with these situations).
(2) Ramp and Tail properties
After much internal debate we have come to the realisation that both of
these properties are not needed, and that in fact one will suffice.
Thus, the kAudioUnitProperty_RampUpTime has been deprecated (and will be
removed from the header).
kAudioUnitProperty_TailTime is still active, and we still hope that many
audio units will report this property. kAudioUnitProperty_Latency is also a
property that is important in this context, as it allows host apps to
determine the time behaviours of a unit, and thus to compensate for any
latency or tail times that a unit reports. We will be updating the docs in
the SDK to provide a more detailed explanation of how these properties work
(in particular tail time).
(3) Duplicate Constant Types:
Both the kAudioUnitType_MusicEffect and kAudioUnitType_Mixer constants for
Audio Units were defined to the value of 'aumx'. Oops!
kAudioUnitType_MusicEffect has been redefined to 'aumf'
Thanks
Bill
--
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.