[linux-audio-dev] XAP: a polemic

[David Olofson]

On Monday 16 December 2002 06.12, Tim Hockin wrote:
> > Still, is the tempo 0, or whatever it is supposed to be at the
> > point where the transport is holding?
>
> <My views>
>
> Tempo remains in effect.

I agree. If you care about transport events, you can find out that 
you're not moving by other means. (Someone told you TRANSPORT_STOP...)


>  Transport time is only meaningful to the
> sequencer.

This is why you can't figure out how beat sync works.


>  Why should a plugin care what point in the song you are
> at?  Why should a plugin care if the play-pointer moves?

That's the only way you can know where you are, in relation to the 
rhythm. Indeed, you could give plugins something like a control that 
ramps from 0.0 to 1.0 over each bar or each beat, but why bother to 
make it a special case? Plugins can just take the song position and 
fmod() it, run it through sin(), or whatever.

The full song position is exactly what you need, only part of the 
information is irrelevant to you. So, you just remove it. Best part 
is that you can lock to any time period you like, such as 16 quarter 
notes.


> 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). Because the sample-counter is tied to the
> tick counter directly via tempo, rate, meter, and ppqn (modulo
> tempo changes, which can come as events or whatnot)

Actually, it's not. It *can* be, but it can alse be sync'ed with 
something external, such as a VCR or an external sequencer.

Either way, by the time you start processing each block, everything 
*will* be tied together for the duration represented by that block, 
or you wouldn't be able to do anything useful.


> plugins don't
> need to actually track what tick number they are on, just the
> passing of ticks.

Again, what is a tick? One QN? One bar? (Whatever that is.)

If you decide on something for this, you also put an absolute maximum 
limit on the period a plugin can deal with. If you get one tick/beat, 
you can't lock to bars, unless they're one beat each. If you get one 
tick/16th, you can lock to quarter notes.


> Edge-dependent plugins, if there is such a
> thing,

Anything beat sync'ed is. ("Auto Choppers", many kinds of 
arpeggiators, beat sync tremolo, etc etc...)


> can see when (samples_per_tick*ppq) samples has elapsed and
> know a beat has happened.

Nope. You must know where to start counting, or you have only tempo 
sync; not positional lock.

For example, if you're "chopping" some audio with an envelope that 
maps to 8ths, and ticks repeated for every 16th, you'd have a 50% 
chance of being off by one 16th.


> > still jam on and have tempo and beat sync effects roll, as if you
> > were looping an empty section in the song. As soon as you start
> > the sequencer again, though, beat sync effects will instantly
> > lock to the timeline.
>
> Absolutely essential, IMHO.
>
>
> Now, I've become very confused.  What is it that we are arguing
> about?

Uhm... Does anyone know!? ;-)


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

Sounds like a good idea.


> * 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?)

I don't think it's a great idea to mix frequency units with period 
units in general. Unit should be ticks/<something>; either 
ticks/second or ticks/sample. The latter makes more sense to me, 
since audio time is the basic unit all plugins must deal with anyway.


>   - PPQN (ticks/qn - host-global? event? fixed?)

PPQN is irrelevant when dealing with fp timestamps. Just make it 1.0 
or something.


>   - METER (units? - event?)

count / value (Two integers. Normally... :-)


> * Plugins can track ticks by adding 1/(rate*tempo) to a counter and
>   observing an integral boundary crossing.

Well, that's part of a solution, but see above, about positional sync.


> So the questions that remain:
>
> * what am I missing?

The positional sync issue, basically.


> * how do external clocks tie in? (I know _nothing_ about them!)

They generally tell the sequencer what position on the timeline it 
should be in at regular intervals. Obviously, this means that the 
sequencer will have to chase or lock it's idea of musical time to 
something that is not related to audio time at all. Thus, the 
sequencer can only map musical time to audio time for one block at a 
time. The sequencer can't know what will happen in the next cycle.


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

Well, I suggested the only unit I've seen used - but there might be 
more generic formats.


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

Well, if you don't care about musical time, there's no tracking work 
at all to do. Just look at the timestamps and process audio.

I've suggested earlier how you would handle TEMPO and POSITION_CHANGE 
events. I can post real code, if needed.


> This argument is getting tired - lets resolve it..

I suspect that the easiest way would be for some of us to implement 
our ideas, so they can be demonstrated and tested in real life 
situations.

Seriously - too much of this discussion is a waste of bandwidth, 
caused missunderstandings and the general complexity of the problem 
space. If we can't get anywhere with english, let's try C, C++ or 
whatever.


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