16 Dec
2002
16 Dec
'02
5:56 p.m.
On Monday 16 December 2002 14.16, Paul Davis wrote:
[...]
Right. That's why I'd like to think of one timeline as basically the
full set of information you get in VstTimeInfo, for the full length
of the timeline. N timelines need N such sets. Audio time is the
*only* thing they're guaranteed to ever have in comon - and that's
only for one block at a time. (One can be audio driven, and the other
sync'ed to a VCR, or whatever.)
Nor do I. And you should never assum anything like this, either way.
It's perfectly sensible to have a plugin do some modulation over a
period of 4 bars, 20 quarter notes, or whatever.
//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 -'
--- http://olofson.net --- http://www.reologica.se ---
you can,
without loss of information, express both as ticks,
and you're back to the uniform timebase.
how so? if ticks are constant-per-beat, i don't see how they can
express the information without the additional beat-per-second
value(s). if ticks are constant-per-second, i don't see how they
can express the information without the additional ticks-per-beat
value(s). any tempo-synced element to an XAP plugin needs to
translate a musical time/duration to a tick value (and thence to
audio frame units). doing this requires two pieces of information,
one of which is not constant across all musical timelines. many uses of
tempo-sync only make use of small note lengths
(16th, 8th triplet etc) so they do not need this mapping.
i don't think that the note length affects this in any way.