Re: AU, plugin tempo, musical time information
Re: AU, plugin tempo, musical time information
- Subject: Re: AU, plugin tempo, musical time information
- From: Paul Davis <email@hidden>
- Date: Tue, 3 Nov 2009 13:42:38 -0500
On Tue, Nov 3, 2009 at 1:24 PM, William Stewart <email@hidden> wrote:
> Paul
>
> I'm not sure what you are actually asking.
>
> We've described how this works, many plugin developers have been using this
> now for a couple of releases of Logic and other host apps, and aside from
> some initial teething problems, it seems to be working ok.
>
> I'm not really sure that you question is really understood, it seemed to me
> more of a commentary about the way you do something different on Linux than
> anything else.
Not at all, it has absolutely nothing to do with Linux whatsoever
(Ardour is a native OS X application, even if we prefer to use
cross-platform GUI and audio APIs rather than tie ourselves to OS X
specific ones). I'll try to restate....
I see two significant issues. The first is the plugin understanding
where it is on a timeline, since the current API:
* only ever tells plugins the position measured in beats and
samples, never bars.
* does not share the tempo map with the plugin
* only provides meter information once per render callback, more or less
I do not see how a plugin can ever compute real knowledge of where it
is on the timeline, since it cannot compute bar position accurately.
Is this intentional? The plugin can know that it is at beat 18.98, but
it has no idea, really, whether this is 2 bars, 4 bars, or 8 bars into
a piece. Is the expectation that fractional beat position is all a
plugin ever needs to know? On an implementation level, this also means
that the host has to (potentially) iterate over the entire timeline
when computing the beat position. Inside Ardour, we store and operate
on "musical time" as BBT time, not fractional beat position, and
although converting from one to the other is implemented, its not
necessarily cheap in a scenario where several plugins require this
every time they render. I'm trying to understand how much I need to
hack in some "optimizations" to handle this sort of situation.
Second significant issue is the comment in the docs (at least the ones
on Tiger - I haven't found them on SL yet) that suggest that beats
really means quarter notes. Contrary to what is claimed in the
documentation, this is *not* standard musical practice. The docs
really don't mandate that 1 beat = 1 quarter note, but they do suggest
it. In the example given in the docs, the beat position supplied to
the plugin will be different depending on which rule one follows. So
what is the rule? Does a host have to count "beats" only as quarter
notes? Do plugin authors fully understand what the resulting value
means, even if the piece is in 3/5 ?
The third less significant issue is the semantics of the
"transportStateChanged" field in the transport state host callback.
There is no definition of "changed relative to what" in the docs that
I've been able to find. Changed since last call? Changed since ???
thanks,
--p
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden