AU2 - beatAndTempoProc
AU2 - beatAndTempoProc
- Subject: AU2 - beatAndTempoProc
- From: Marc Poirier <email@hidden>
- Date: Tue, 17 Sep 2002 15:29:21 -0400
Hi. I'm glad to see that there is a means for getting tempo and beat
information from hosts in Audio Unit 2.0 However I fear that the
current implementation is pretty inadequate.
First of all, the meaning of "beat" is not defined. It's not
explained in the documentation, and I for one can think of at least 5
things that it might express. (And the host I'm currently working
with returns values that don't fit into any of those 5 categories, so
I don't know what to make of it.)
Secondly, there's no way to find out where the next or previous
measure begins, in relation to the current "beat." This is necessary
in order to be able to align sounds with measures.
Thirdly, there's no way to find out what the time signature is. This
necessary if you're trying to make something happen on a per-measure
basis. It would also help with the 2nd problem I mentioned, although
it wouldn't be sufficient (measure information would still be
required) since time signatures can change.
Fourthly, with the current values that are available (tempo and
beat), there's no way to determine their validity. What if a host
can provide tempo but not beat? Or beat but not tempo? One might
think that the return value from beatAndTempoProc() could be used to
indicate validity problems, but the return values are currently
undefined (or at least undocumented).
So basically the problems are: not enough tempo/time information is
available from the host, no way to verify the validity of tempo/time
information, and not enough documentation. Only you Apple folks can
fix the third problem. ;) I have a couple ideas for the first two:
idea #1: More values could be added to beatAndTempoProc(). It could
be something like beatAndTempoAndMeasureAndTimeSigProc(void
*inUserData, Float64 &beat, Float64 &tempo, Float64 &measurePos,
Float64 &timeSigNumerator, Float64 &timeSigDenominator). Then you
could define validity flags that would be set in the return from that
function, so that individual flags would be set for each of those
bits of information.
idea #2: There could be multiple functions in the HostCallbackInfo
struct rather that just one. There could be beatProc, tempoProc,
measurePosProc, and timeSigProc. Validity of these could be verified
either by return values (which is easy now; there's only one piece of
information per function) or by simply having hosts set the pointers
to those functions as NULL if the host doesn't support that
particular feature.
I prefer idea #2, personally.
Marc
P.S. - I hope you don't mind me picking apart this aspect of the
API. In general, the more I learn about AU2, the more I like it, and
I think, for the most part, it's a much better music plugin API then
those that preceded it. But given the fresh start that we have with
AU, I hate to see it be less capable than its predecessors in certain
ways. If these time/tempo capabilities do not become a part of AU,
then the majority of my plugins will not work as well in AU-form as
they did in VST-form, which would be very unfortunate, especially
after I've told so many people how much better AU is than VST. ;)
_______________________________________________
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.