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 19:36:55 -0800
On Nov 3, 2009, at 6:47 PM, Paul Davis wrote:
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?
I think you are making this more complex than it is intended to be.
by "changed" it is meant that *anything* about the transport that is
not completely contiguous from the last state has changed from *when*
you last asked.
It is a provided as a guide to tell the AU that any assumptions it is
making about the state of the transport have been broken. It doesn't
tell you why, or list an exhaustive set of conditions because we (or
the host) don't know what you are basing your assumptions on. By
"state changed" we also aren't talking about say a slewing of the
clock through some jittery MTC - that might be changing the tempo
around, etc, but its not a fundamental change of state of the
transport (like a start/stop is, or jumping to a new time, etc)
Another example of this is the audio queue timeline object. It has a
boolean that indicates there was a discontinuity in the timeline (and
of course, just as in this, the implicit assumption is that this
discontinuity occurred since the last time you asked). Now, you know
there is a discontinuity, you go figure out your new anchor point,
etc, based on what information you are relying on. Same for the
hostTransportChanged bool - something changed...
Bill
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>) |
| | >Re: AU, plugin tempo, musical time information (From: Paul Davis <email@hidden>) |