> 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..
