Subject: Re: [linux-audio-dev] XAP: a polemic
From: David Olofson (david_AT_olofson.net)
Date: Mon Dec 16 2002 - 05:06:06 EET
On Monday 16 December 2002 03.18, Tim Goetze wrote:
> Tim Hockin wrote:
> >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?
>
> i usually intersect the beat interval giving function with
> the current processing cycle. i don't quite know what you
> mean by milestones, it does sound like meta-information to
> me (like "begin song part A here", "isolde stirbt", etc).
I think he meant "start of beat" and that kind of stuff, rather.
("isolde stirbt" would be a change of a string Control of some weird
plugin. ;-)
> >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?
>
> it's much simpler. imagine the transport time rolling on
> through a 'stop',
That's basically what I'm suggesting *plugins* could do, if they
like. They would still be told about TRANSPORT_STOP, of course, in
case they actually *want* to stop.
> and some plugins handling things a bit
> differently.
That's what I don't quite like. I'd prefer if plugins that don't care
could... well, just not care! :-)
With audio timestamps, that would be very easy, and I'm still failing
to see how there can be any complications in dealing with musical
time, just because you stamp events with something else, that has a
known relation to musical time for every sample of the current block.
1. There can never be a question about when an event
is meant to be applied. (You will process for N
sample frames, or there will be trash in the audio.
Likewise with events - and they're based on audio
time.)
2. 1 applies to the sequencer as well - so it will
*have* to have decided how to map musical time to
audio time, before it lets other plugins run. There
is a known, fixed relation for every sample in the
block.
3. Given 1 and 2, you can always translate an event
that you're supposed to process, into musical time,
with sample accurate timing.
4. If you want to manipulate timing of events in
relation to musical time, you will have to consider
the fact that no one knows the exact mapping of
musical time to audio time in future blocks.
5. Given 1 and 4, you can wait until the musical time
you're interested in is within the current block.
Not until then can you make a final and correct
decision.
//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 ---
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 05:12:26 EET