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 21:47:07 -0500
On Tue, Nov 3, 2009 at 8:56 PM, William Stewart <email@hidden> wrote:
> 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.
OK, thanks, I'll take that as a clarification. My confusion stems from
the fact that I do not believe that it *is* common practice. Since the
docs I was reading date from Tiger, I wondered if this had been
clarified or altered since. 1 beat = 1 quarter note, so it shall be.
>> 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.
changed since *what* ? since the last time the plugin asked? what if
it changed between the plugin asking, but multiple times and is now
the same as when the plugin last asked? what aspects of transport
state are allowed ? what if one host has elements of "transport state"
that another doesn't.: does changing the value of ardour's
"auto-return" as a transport option mean that transport state has
changed? what if we used to be synced to MTC and now we are not? what
if we are still trying to sync to MTC but have dropped out of lock?
what if we were moving at speed == 1.0 and now we are moving at speed
0.89? does reversing direction count as a transport change?
in a nutshell: since the plugin knows the current values of all the
other (out) arguments to this callback, and presumably can cache the
previous values if it cares, what more is the host supposed to be
indicating by setting this argument to true or false?
> 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).
that part is very clear, no issue there. I was mentioning it here only
because the 3 host callbacks outlined in the docs are all on the same
page, so to speak.
_______________________________________________
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>) |
| | >Re: AU, plugin tempo, musical time information (From: William Stewart <email@hidden>) |