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