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?
