12 Dec
2002
12 Dec
'02
9:06 a.m.
On Thursday 12 December 2002 13.32, Steve Harris wrote:
On Thu, Dec 12, 2002 at 12:16:09 +0100, David Olofson
wrote:
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?
For example, if you're delaying events by musical time, you're not
*allowed* to keep the audio time of a future musical times, since it
may be invalid by the time you get there. (Timeline edits or
transport manipulation.) So, you only really have to know that the
event *is* in the future, so you can put it in your internal queue
for processing later on.
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.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
I (still) don't think musical time belongs in
timestamps of your
average event in XAP. Those events are meant to act as an
alternative to audio rate controls or blockless processing. The
host gives you a time frame to work with (expressed as a number
of audio frames), and that's the timeframe you're meant to work
with. This applies to audio as well as events.
I agree. For efficiect reasons if nothing else, having musical
events mixed in with your data events would make it very hard to
parse.
Musical time can be expressed in the same way it is in VST (as I
understand it) or jack and friends.
It does need to be part of the API, but not mixed in with the (very
low level) event system.