Re: AU, plugin tempo, musical time information
Re: AU, plugin tempo, musical time information
- Subject: Re: AU, plugin tempo, musical time information
- From: William Stewart <email@hidden>
- Date: Tue, 3 Nov 2009 17:56:37 -0800
On Nov 3, 2009, at 3:57 PM, Paul Davis wrote:
On Tue, Nov 3, 2009 at 4:59 PM, James McCartney
<email@hidden> wrote:
In any case arguing this is quite academic since the API has shipped.
I'm not really attempting to argue it, although i think it is an
interesting discussion, albeit not for this list. The docs are not
really clear on whether on not "beat == quarter note". I asked for
clarification. Doug seemed to be offering a defense of "beat ==
quarter note", but i have still not seen a clear statement on whether
this is what plugins should expect from the host ...
I'm sorry, but I don't agree at all (and this goes back to my original
confusion about your post). Here's the relevant quote from the docs:
>>>
Score Time Sig: |3/4 | |4/8 |6/8 |5/8 |3/4 |
4/4 |
Down Beats: 0 3 6 8 11 13.5
16.5 20.5
For a change from 3/4 to 4/8 the value of the beat does not change
(thus, a 4/8 time sig will still have 2 beat values for that measure -
the value of the beat unit does not change as the time signature
changes). In common practise a beat is generally associated with a
quarter note.
>>>
That seems pretty clear to me about what the plugin should expect.
it also remains unclear how plugins can identify their position beyond
beat position since they have no access to a tempo map, nor can they
handle meter/tempo changes that occur in the middle of a rendered
buffer.
we don't - it is, like I said previously, something that has not
really come up in practice as a critical issue. If this is something
that we should address, then I am happy to have a conversation about
this
While the conversation about musicians and musical scores is
interesting, I don't see us changing the basic way we deal with this -
as the previous discussion has alluded too, any way that you deal with
this has its drawbacks, its adherents and detractors. So, any
additional semantics we added here would need to fit within the
general framework we have already established.
it would be interesting to hear how the API is intended to
handle, or is not intended to handle, these issues. finally a clear
state on precisely what "transportStateChanged" is supposed to be
relative to would be nice.
From the same docs:
Indicates that some state of the host's transport has changed. For
instance, the time-line has started or stopped, the position within
the time-line has changed (for eg. the SPL has been moved to a new
location, or the transport is in cycle mode, and has jumped from the
end back to the start of the cycle)
What exactly is confusing you about this? This has no relationship to
a change in tempo, key or time signature (as none of this falls into
the notion of transport state).
Bill
_______________________________________________
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
| References: | |
| | >AU, plugin tempo, musical time information (From: Paul Davis <email@hidden>) |
| | >Re: AU, plugin tempo, musical time information (From: Doug Wyatt <email@hidden>) |
| | >Re: AU, plugin tempo, musical time information (From: Richard Dobson <email@hidden>) |
| | >Re: AU, plugin tempo, musical time information (From: Doug Wyatt <email@hidden>) |
| | >Re: AU, plugin tempo, musical time information (From: Paul Davis <email@hidden>) |
| | >Re: AU, plugin tempo, musical time information (From: James McCartney <email@hidden>) |
| | >Re: AU, plugin tempo, musical time information (From: Paul Davis <email@hidden>) |