Conclusion:
a. The information is there, but you have to *pull*
it from the host. Doesn't seem like you're ever
notified about tempo changes or transport events.
b. Since you're asking the host, and there are no
other arguments, there is no way that one plugin
can keep track of more than one timeline. It
seems that it is assumed that there is only one
timeline in a net.
So all the mechanisms we're discussing are more flexible? Obviously we
don't have EVERYTHING hammered yet..
3. There are calls that allow plugins to get the audio
input
and output latency.
Conclusion:
c. I'm assuming that this is mostly useful for
VU-meters and other stuff that needs to be
delayed appropriately for correct display.
Obviously not an issue when the audio latency
is significantly shorter than the duration of
one video frame on the monitor! ;-) Seriously
though, this is needed for "high latency"
applications to display meters and stuff
correctly. They're not very helpful if they're
half a second early!
yeah, this is now on the TODO list
4. There is a feature that allows plugins to tell the
host
which "category" they would fit in. (There is some
Ick - external.
9. There is a bypass feature, so that hosts can have
plugins implement sensible bypass for mono -> surround
and other non-obvious in/out relations. (As if in/out
relations ever were to be assumed "obvious"!)
not clear what you mean..