Re: AU2 - beatAndTempoProc
Re: AU2 - beatAndTempoProc
- Subject: Re: AU2 - beatAndTempoProc
- From: Art Gillespie <email@hidden>
- Date: Thu, 19 Sep 2002 23:11:36 -0400
There isn't much to add to this that hasn't already been pointed out.
(Except comforting reassurance from our friends at Apple that this
issue hasn't been overlooked). But I just wanted to make a couple of
points.
- AFAIK, every sequencer I've ever touched measured ticks in ppq (Pulse
Per Quarter). In point of fact, without looking it up, I'm pretty sure
SMF files use the same notion when determining the resolution of the
running length info... so I'm not sure that settling on quarternote as
the definition of beat is such a bad idea. But frankly, defining beat
to correspond to the current-phase-of-the-moon would be better than to
not have it defined at all in the spec and leave it to host and plug-in
developers to interpret.
- Our current and planned products will be completely beached in AU if
there's no way to phase lock to bar/beats, which requires that I can
get per-buffer delta to next/previous bar information (by whatever
means... I like Paul's suggestion about ScheduledParams, though it's
not immediately apparent to me how it would work). I think that a lot
of products coming from VST-land will have the same requirement (i.e.,
any that need to synchronize to the host).
- it's not clear to me how to determine the transport state of the
host. Have I missed something obvious?
I'd humbly suggest that the ComponentType/SubType in the MultitapAU
example be updated to v2 semantics (or the default search behavior of
AudioUnitHosting changed) in a future release of the SDK. So as not
to start off everyone's experience with AU2 on the wrong foot. That
was frustrating as hell.
Best,
Art
>>0xBA
_______________________________________________
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.