Re: AU HostCallback - musical location
Re: AU HostCallback - musical location
- Subject: Re: AU HostCallback - musical location
- From: Jeremy Sagan <email@hidden>
- Date: Fri, 16 May 2003 18:15:58 -0400
I am looking at the spec for musical location. In the December 2002
tools there is no definition of the flags field.
Has this been implemented? If so, where is the appropriate
AudioUnitProperties.h file?
Thanks,
Jeremy
On Tuesday, October 1, 2002, at 08:59 PM, Bill Stewart wrote:
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.
_______________________________________________
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.