Re: AU HostCallback - musical location
Re: AU HostCallback - musical location
- Subject: Re: AU HostCallback - musical location
- From: Bill Stewart <email@hidden>
- Date: Tue, 01 Oct 2002 17:59:56 -0700
on 28/9/02 7:10 AM, Marc Poirier wrote:
>
One little point of ambiguity remains, though. "Beat" in beatAndTempoProc
>
is still not totally defined, although the meaning is much clearer now.
>
The only thing that might be ambiguous is what zero represents and if the
>
value ever resets. I am guessing that 0 would be at the start of the song
>
and that the value continues to increase throughout the song (I am
>
guessing this given the way that outCurrentMeasureDownBeat is defined),
>
but it could also be possible that beat resets to zero at the start of
>
each measure, so I think it would be worth explicitly spelling out the
>
expected behaviour in that respect.
It is expected that a value of beat as zero is the start of the song - it is
not a reset...
>
There are also four other properties that I think might be valuable to
>
plugins. These are basically changed-state indicators, which I think
>
would be quite useful:
>
>
* whether or not playback is currently occurring (because some apps still
>
process audio even when playback is stopped)
If beat/tempo/etc information is NOT applicable when an AU calls for that
information (lets say that you're processing live input and thus the host
may have no concept of beats and tempo) - then the host returns an error
code from either of these callbacks.
The error code returned would be:
kAudioUnitErr_CannotDoInCurrentContext = -10863
(This is the same error code number as kAUGraphErr_CannotDoInCurrentContext
- but as the calling context is quite different we don't see any area where
this would cause confusion - and the meaning of this result code is
basically the same)
>
* whether or not the playback location has jumped somewhere new for this
>
rendering buffer (eg SPL was just moved, cycle looped, etc.)
OK
This would then look like this:
// Any of these parameters when called by the AudioUnit can be NULL
// (except for the HostUserData which must be supplied by the AU as given to
it when the property was set)
//
// outDeltaSampleOffsetToNextBeat - will contain the number
// of samples until the next beat
// from the start sample of the current rendering buffer
// outTimeSig_NumBeats - the number of beats of value "beat type"
// that is contained in the current measure
// outTimeSig_BeatType - 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_NumBeats,
UInt32 *outTimeSig_BeatType,
Float64 *outCurrentMeasureDownBeat,
UInt32 *outFlags);
typedef struct HostCallbackInfo {
void * hostUserData;
HostCallback_GetBeatAndTempo beatAndTempoProc;
HostCallback_GetMusicalTimeLocation musicalTimeLocationProc;
} HostCallbackInfo;
// where flags can have one of the following values
enum {
kMusicalTimeLocation_NewPlaybackPostion = (1L << 0)
//playback position has JUMPED - is not contiguous from previous call
};
>
* whether or not the time signature just changed (warn a plugin that is
>
just "riding" on its current understanding of the meter that it should
>
strategize)
>
>
* whether or not the tempo has just changed (similar to above)
The AU has to know about the time sig and the tempo if its doing anything
with them. As these are passed in directly, it is easy enough to determine
that its different than the last time this has changed.
>
Yup, give me a slice of bread and I'll try and take the whole loaf... ;)
>
>
>
> To add the additional support that has been discussed we're proposing
>
> the following:
>
>
>
> typedef struct HostCallbackInfo {
>
> void * hostUserData;
>
> HostCallback_GetBeatAndTempo beatAndTempoProc;
>
> HostCallback_GetMusicalTimeLocation musicalTimeLocationProc;
>
> } HostCallbackInfo;
>
>
>
> An AudioUnit can determine if its being called for just the first proc
>
> through checking the size of the passed in data proc.
>
>
Oh, this reminds me of a little (possible) bug I found a while ago: In
>
AUBase.cpp, memcpy is used for kAudioUnitProperty_HostCallbacks in
>
DispatchSetProperty, but an assignment is done in DispatchGetProperty.
>
This is fine for now given the struct, but might be an issue in the
>
future, so memcpy probably should be used in both cases, I think...
>
>
>
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.
--
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.