[linux-audio-dev] XAP and Event Outputs

David Olofson david at olofson.net
Wed Dec 11 15:21:01 UTC 2002


On Wednesday 11 December 2002 19.42, Tim Hockin wrote:
> > delays based on musical time do, whatever you like to call
> > it.
>
> I always assumed that tempo-delays and thinsg would just ask the
> host for the musical time at the start of each buffer.

That's a hack that works ok in most cases, but it's not the Right 
Thing(TM), if you're picky.


> With
> sample-accurate events, the host can change tempo even within a
> buffer.

Yes. And it can also slide the tempo smoothly by changing it once per 
sample. To be entirely safe, you must take that in account.


>  If a plugin is concerned with muscial time, perhaps it
> should ask for the musical time at the start and end of the buffer.
>  If the musical time stamp the plugin wants is within the buffer,
> it can then find it and act.

Yes, that could work...


> This breaks down, though when the host can do a transport
> mid-buffer, and sample-accuracy permits that.

Yes.


> Perhaps plugins that
> care about musical time should receive events on their 'tempo'
> control.  Tempo changes then become easy.

Great idea!

For MAIA, I once had the idea of sending musical time events - but 
that would have been rather useless, as the host/timeline 
plugin/whatever couldn't sensibly send more than one event per buffer 
or something, or the system would be completely flooded.

However, tempo changes would only occur once in a while in the vast 
majority of songs, and even if the host limits the number of tempo 
change events to one every N samples, plugins can still work with 
musical time with very high accuracy.

And, there's another major advantage with tempo: Whereas looping 
unavoidably means a "skip" in musical time, but does *not* have to do 
that in tempo. If your whole song is it 120 BPM, you'll probably want 
arpeggiators and stuff to work with that even if you loop.

This is not the whole answer, though. As an example, you'll probably 
want an arpeggiator to be able to lock to musical *time*; not just 
tempo. That is, tempo is not enough for all plugins. Some will also 
have to stay in sync with the timeline - and this should preferably 
work even if you loop at weird ponts, or just slap the transport 
around a bit.


> Transports are still
> smarmy.

They always are. To make things simple, we can just say that plugins 
are not really expected to deal with time running backwards, jumping 
at "infinite" speed and that kind of stuff.

However, it would indeed be nice if plugins (the ones that care about 
musical time, that is) could handle looping properly.


> Is it sane to say 'don't do a transport mid-buffer' to the
> host developers?

I don't think that helps. Properly implemented plugins will work (or 
be confused) no matter when you do the transport operation.

Don't think too much in terms of buffers in relation to timestamps. 
It only inspires to incorrect implementations. :-)


So, what's the Right Thing(TM)?

Well, if you have an event and want it in musical time, ask the host 
to translate it.

If you want the audio time for a certain point on the musical 
timeline, same thing; ask the host. In this case, it might be 
interesting to note that the host may not at all be able to give you 
a reliable answer, if you ask about the future! How could it, when 
the user can change the tempo or mess with the transport at any time?


Now, if you want to delay an event with an *exact* amount, expressed 
as musical time, translate the event's timestamp into musical time, 
add the delay value, and then ask the host about the resulting audio 
time. If it's within the current buffer; fine - send it. If it's not, 
you'll have to put it on hold and check later.

There are at least two issues with doing it this way, tough:

	* You *will* have to check the order of events on your
	  outputs, since musical time is not guaranteed to be
	  monotonous.

	* You'll have to decide what to do when you generate an
	  event that ends up beyond the end of a loop in musical
	  time. Since you cannot really know this, the "correct"
	  way would be to just accept that the event will never
	  be sent.

So, if you only want an exact delay, you're probably *much* better of 
just keeping track of the tempo. It's so much easier, and 
automatically results in behavior that makes sense to the vast 
majority of users.


It's more complicated with a timeline synchronized arpeggiator, which 
*has* to keep track of the timeline, and not just the tempo. Sticking 
with the tempo idea and adding a PLL that locks the phase of the 
internal metronome to the timeline would probably be a better idea.

And no, timestamps in musical time would not help, because they don't 
automatically make anyone understand which events belong together. 
Even if they would, the *sender* of the events would normally know 
best what is sensible to do in these "timeline skip" situations. You 
would not be able to avoid hanging notes after looping and that kind 
of issues, since timestamping your events in musical time locks them 
to the *timeline*, which means they can be "lost forever" if you loop.


//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 -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---



More information about the Linux-audio-dev mailing list