[linux-audio-dev] XAP: a polemic

Paul Davis paul at linuxaudiosystems.com
Mon Dec 16 08:38:01 UTC 2002


>Tempo remains in effect.  Transport time is only meaningful to the
>sequencer.  Why should a plugin care what point in the song you are at?  Why
>should a plugin care if the play-pointer moves?

a tempo-sync-using plugin doesn't care about song position, true. it
only cares about tempo at a given point. so yes, its correct to
disconnect these.

but keep in mind that some other plugins (possibly, or even likely)
the same ones) will also care about transport information as well. 

if you take a look in ardour, you could consider its AudioTrack
objects to be disk-based samplers. they operate quite differently
depending on whether the transport is rolling or not (generating
silence (after a declick!) if not, and streaming data to/from disk if
it is).

>Audio time (sample-count) runs endlessly (host can actually stop it if it
>can know there is nothing going on at all, perhaps - blocked on user/MIDI
>- maybe).  

actually, probably not. you generally want to assume that the audio
interface runs continuously - many hardware devices generates clicks
when started, and in addition, if used in combination with other
digital devices, you end up with sync/lock issues.

>Now, I've become very confused.  What is it that we are arguing about?  We
>seem to all be talking in circles, so I'm going to describe what I
>understand and I want to steer the discussion towards a solution :)

good plan.

>* Host sends buffers of N samples to plugins, with a starting timestamp
>* Things send timestamped events to plugins
>* Timestamps are measured in whole audio samples
>* Host/timeline must export/deliver:
>  - SAMPLE RATE (samples/sec - passed at instantiation)
>  - TEMPO (sec/tick - event?)
>  - PPQN (ticks/qn - host-global? event? fixed?)

i suggest forgetting this. VST sets it to 1 PPQN, and treats "QN" as
"1 beat", so the information is really quite useless. there's no need
for it given TEMPO and METER.

>  - METER (units? - event?)
>* Plugins can track ticks by adding 1/(rate*tempo) to a counter and
>observing an integral boundary crossing.
>
>So the questions that remain:
>
>* what am I missing?
>* how do external clocks tie in? (I know _nothing_ about them!)

they don't, except that they may move time in mysterious ways (stop
it, move it at variable rates, move it backwards, etc).

>* units for meter (I don't know enough music theory to answer properly)

after much discussion about this on ardour-dev, we settled on beats
per minute, where beats are whatever unit the time signature is
using. for some music, the unit is irrelevant, because nothing else
uses subdivisions of the beat note value in any coherent way (i.e. you
can decide that a beat is a quarter note, or a half note or a whole
note, and nothing else will care). for other music, its important that
the beat value is known.

>* can we take any of this tracking work away from the plugins?

well, i think you haven't yet defined quite how the plugin gets the
information. after the discussion about callbacks, i return to
favoring events delivered to a Well Known Control. to flesh out what
you suggest about:

    SAMPLE_RATE (samples/sec, passed at instantiation)
    TEMPO (samples-per-beat, delivered as an event, see below)
    METER (beats-per-measure + beat-note-value, delivered as an event)
    
the TEMPO event needs to include:
     
     samples-per-beat (as a floating point value) [ time between beats ]
     ramp slope  (possibly 0)  [ for accelerando and ritard ]
     ramp target (irrelevant if ramp slope is zero) [ ditto ]
     
the METER event needs to include

     beats-per-measure (floating point value) [ 3, 5, 7, 9.5 etc ]
     beat-note-value (floating point value) [quarter,1/16th, etc]

in addition to this, the host/API needs to provide two other
functions:

    "get current time information"
	 
	 - the structure needs to be based on the VST time info structure.
	   it will indicate the sample position of the next beat, and
	   the next bar. it will indicate the state of the transport,
	   including loop information in the way that JACK's time info
	   structure does. it can only be called from the "process"
	   handler of the plugin, because the information is all
	   specific to the current block being processed.

    "convert musical time"

         - passed a musical time (B|b|t) and an indicator of which
	   timeline to use, it returns the audio frame at which
	   the event will occur, independent of transport state.
	   if transport state matters, the plugin will have to 
	   handle that itself. this function doesn't require host
	   information, but it does require a way to access
	   a (possibly) shared timeline and it needs to be implemented
	   only once :)

i haven't followed the rest of the XAP discussion to know how Well
Known Controls would be established, but if a plugin needs tempo sync
it should go through whatever steps are necessary to define a "tempo"
control, which will receive TEMPO and METER events as necessary.

we might add a BEAT event, which would be delivered by the host on an
intermittent basis, and would contain:

     beat number
     tick number
     sample position

this will allow tempo-synced plugins to align to what has been called
the tick edge. beats are sufficiently intermittent that this doesn't
cause an event overload even if one is sent for every beat. however,
there is no need to do this - it would be find to deliver one every
time the transport state changes to "moving" so as to resync everybody
who cares.
    
--p





More information about the Linux-audio-dev mailing list