[linux-audio-dev] XAP: a polemic

David Olofson david at olofson.net
Mon Dec 16 19:59:00 UTC 2002


On Monday 16 December 2002 21.21, Tim Goetze wrote:
[...]
> >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.
>
> you absolutely need ppq for the tick system to properly map
> different measures (5/4 time, 6/8 time etc) as per previous
> post.

I'm not sure if you absolutely need it (you *can* translate), but 
indeed, it's *much* nicer when the "speed" of musical time depends 
only on tempo, and not the whole meter. (IMHO, that x/y thing is 
basically an irrelevant higher level grouping most of the time. Have 
plugins ask for the meter info if they care.)


> >>* 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.
>
> you're better off specifying tempo as quarter beats/minute
> uniformly for the above reasons.

Quarter *note*, you mean?

(One usually says that 1 beat == 1 quarter not, so...)

Dunno about minutes, but hey, most people know how many seconds there 
are in a minute, and it's THE standard unit for tempo, so people 
probably go "Huh!?" if you say it's in beats/second. :-)


[...]
> >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 ]
>
> add seconds-per-beat for plugins that are not limited to
> audio purposes.

How about checking the audio sample rate? (Yes, that will not map 
exactly to seconds, but it *would* allow you to have the same idea of 
"1 second" as your wordclock sync'ed audio devices, which seems much 
more useful to me.)

If you want to deal with *actual* wall clock time to do some I/O, 
you're in the wrong thread (host audio thread) and/or asking the 
wrong questions, I think.


> >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]
>
> i wouldn't make either a float, it is by far too uncommon
> to be justified and makes some arithmetic cumbersome.

Yes... Maybe. (Depends on what kind of calculations you do. Can't 
think of any problems with beat sync effects, at least.)

Anyone here ever used non-integer # of beats/bar, and/or "weird" note 
lengths?


> >    "get current time information"
[...]
> >    "convert musical time"
[...]
>
> from my experience, more conversion functions are needed, in
> effect you need to map from any of these domains to any other:
>
>  * bar.beat.fractional (or .tick if you will),

Trivial if you have musical time and meter info.


>  * tick

Have TEMPO and POSITION_CHANGE Controls, and you'll be able to keep 
track of that. (With subsample resulotion, except for the actual 
timing of transients; those can only be sample accurate.)


>  * time in seconds

What time? Wall clock? If you have the current time info struct, 
it'll contain that (as calculated by the timeline "driver", based on 
audio latency), and then you can convert back and fort as you like 
by, though musical time position/"tick".


>  * audio frame

That's our basic unit, so that's easy.


> you may want to implement it using one call and a structure
> with flags denoting your interest,

That's what VST does. Might save some cycles.


> or offer any of these as
> a separate function. i have opted for the latter -- to keep
> things sane, b.b.f conversion is only done for ticks and
> vice versa though.

Yeah, it's just that that would be a *lot* of calls if you want to 
cover all combinations. Look at VST's VstTimeInfo, or whatever Paul's 
corresponding struct in JACK is called; those cover what you need. 


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



More information about the Linux-audio-dev mailing list