On Thu, Dec 12, 2002 at 02:01:45PM +0100, David Olofson wrote: > > It does need to be part of the API, but not mixed in with the (very > > low level) event system. > > Right. So, what we need to do now is agree on a sensible time struct. > That is, basically copying that of VST or JACK.
OK, sorry, I may have misunderstood the current state of the discussion, I've not been following this thread as closly as the pitch one. > I'm trying to find out whether or not it makes sense to say anything > more than "in the past" or "in the future" about timestamps that are > outside the buffer... Do you ever have a *valid* reason to query the > musical time of an audio time that is outside the time frame you're > supposed to work within? I think it depends on how expressive your time struct is. You do need to know what the delay time would be from now, assuming no changes. > Anyway, the *real* reason why I'm worrying about this is that such a > rule could make life a lot easier for hosts. You can cache time > structs for the current buffer, but never have to even generate them > for timestamps that fall outside. (The call would just return one of > two error codes or something.) As long as you have musical time information you can extrapole from there when you need to. Or is that what you're trying to stop? - Steve