[linux-audio-dev] XAP: a polemic

[David Olofson]

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 ---