12 Dec
2002
12 Dec
'02
10:37 a.m.
On Thu, Dec 12, 2002 at 02:01:45PM +0100, David Olofson wrote:
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.
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. 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