Subject: Re: [linux-audio-dev] XAP: a polemic
From: Tim Hockin (thockin_AT_hockin.org)
Date: Mon Dec 16 2002 - 03:01:45 EET
> >Standing proposal:
> > Host processes blocks of 'n' samples. Events are delivered with a
> > timestamp that says 'actuate this event at this time within this buffer'.
> > This is exactly what user-supplied automation is, totally randomly timed
> > events. Some plugins need to sync to tempo or music-milestones. They
> > indicate this need and receive tempo, meter, ticks events. It is
> > responsible for tracking changes.
>
> drop the tick events and it starts to sound reasonable.
Ok. So how does a plugin know about musical milestones, then? Suppose it
wants to lock onto a beat edge. I agree that TICKS events are not needed,
since if you know the sample rate (you do) and you know the tempo (you can),
then you can extrapolate a tick-width. The tick edge is the trick. Or do
we not worry about it and assume that the user will start things at the
proper edge, and plugins will just need numbers of tick-widths?
> buffer-relative timestamps are a definite no.
Yeah, I didn't mean it to come across that way - we've already decided that
timestamps are continuous. Sorry for the miscommunication.
I don't get what you were saying about virtual time. Let me try:
frame-count is a global rolling counter. It never stops, unless the host
has a special 'off' mode. Ticks is a mucial counter starting at some point,
0, that represents the timeline (track/song/whatever). It can jump forward
(12, 13, 165) or backward (165, 166, 1) or loop, or pause. If it is paused
or stopped, the frame-counter is still going. Since plugins just track
'ticks' by that, they still work.
Is that correct?
Tim
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 03:05:40 EET