[linux-audio-dev] XAP Time/Transport - varispeed/shuttle

Paul Davis paul at linuxaudiosystems.com
Thu Dec 19 09:47:01 UTC 2002


>SAMPLE_RATE:  all plugins know this from create()
>  - units: frames/sec (uint32)
>
>TEMPO:  a plugin can have a TEMPO control
>  - units: ticks/sec (float)
>  - deliver a TEMPO event at plugin init and whenever the tempo changes
>
>TIMEBASE:  (FIXME: instance-constant by host/user or a dynamic event?)
>  - units: ticks/beat (int or float?)

float. for all integer tempo/meter setups, we'll fit things with no
rounding into the 24 bits of a float, yet we'll still allow for other
things as well.

>  - let our docs suggest 1920 or 2520
>    - 2520 is divisible by 2,3,4,5,6,7,8,9,10,12,14,15,18,20 and more

nice! i'll change ardour to use this value immediately.

>METER:  a plugin can have a METER control (or controls)
>  - units: ticks/measure
>  - deliver a METER event at plugin init and whenever the meter changes

i think that ticks/measure is a nice idea. combined with ticks/sec for
tempo, you can compute everything you need. however, i don't see how
you can derive the actual western A/B form from just this information,
and this might be necessary for some purposes.

>TRANSPORT: a plugin can have a TRANSPORT control
>  - units: absolute ticks (double)
>  - deliver a TRANSPORT control when transport starts (start tick),
>    jumps (new tick value) and periodically (recommend each beat or each
>    measure or 1/sec).  Reccommend to send on tempo/meter changes, too
>  - special event TRANSPORT_CTL - parm = start/stop/freeze
>    - do we really need a special event? see below...
>
>In addition to the above, the host can enable:
>
>	/* find out the timestamp of the next beat or bar */
>	uint32_t next_beat = host->time_next(XAP_NEXT_BEAT);
>	uint32_t next_bar = host->time_next(XAP_NEXT_BAR);
>
>	/* get time info about a timestamp, assuming current tempo, etc */
>	XAP_timeval times;
>	int r = host->get_time(timestamp, &times,
>	    XAP_TIME_TICKS | XAP_TIME_WALL | XAP_TIME_SMPTE);
>	//FIXME: other time domains?
>
>	/* find out what the transport is doing */
>	XAP_transport trans = host->get_transport();
>
>In addition to all that, some sort of CUEPOINT mechanism as proposed to id
>loop-points, or simpler just a get_loops() method.

i think that having multiple methods to ask about "current" time is a
mistake. i think that VST's approach is better: have a single function
that retrieves all the information (actually, in VST, you set a
bitfield to specify which information you want). the host doesn't
compute anything till the first call to the function (by a plugin),
thereafter, it uses the precomputed value of the struct that holds the
data. thus:

      typedef struct __xap_timeinfo {
	      ... somewhat like VST ...
      } XAP_timeinfo;

      XAP_timeinfo* time;

      time = host->get_timeinfo(... possible bits ...);

>NOTE: with this dataset, changing the meter impacts the perceived tempo.
>Since we decided to say tempo is actual BEATS, and the value of beats can
>change, and ticks is dependant on beats:
>
>Rate = 48000 samples/sec
>Timebase = 100 ticks/beat
>Tempo = 120 beats/minute = 2 beats/sec = 200 ticks/sec
>Meter = 4/4 = 400 ticks/measure
>=> a measure is 2 seconds (4 beats at 2 beats/sec)
>
>change Meter to 8/8
>=> a measure is 4 seconds (8 beats at 2 beats per second)

that seems entirely correct to me, but then i'm not a musician. when
i've asked my musician friends, i get two responses. the rock/pop
people are used to 1 beat = quarter note and tempo =
quarters-per-minute. the classical folks are more experienced with
tempo being denoted in beats-per-minute, and found the idea of it
being forced to be quarters-per-minute rather odd. so you'd have two
different responses to this. the classical people i know would find
this sensible; the rock/pop people might find it odd that the tempo
continues to be N of some unit, yet the apparent tempo has changed
(because they aren't used to the idea that the unit of tempo is a
beat, not a quarter note).

>What if we had plugin-global notifier events that told the plugin some
>things:
>  TRANSPORT_STATE start/stop events
>  CUEPOINT add/remove
>  TIMEINFO - something time-ish has changed
>  TIMEBASE change
>  METER change
>  TEMPO change
>
>Some of those may actually be best left as controls (TEMPO, METER,
>TIMEBASE?).  We could have a CUEPOINT control but it's getting ugly.  We
>could have special events for TRANSPORT start/stop but uggh.
>
>Now I know that making some of this plugin-global means that different
>channels can't be on different timelines, but honestly, I don't think it
>matters :)

i would agree with this. i think its a very sensible idea.

--p



More information about the Linux-audio-dev mailing list