15 Dec
2002
15 Dec
'02
11:11 p.m.
On Monday 16 December 2002 03.18, Tim Goetze wrote:
That's basically what I'm suggesting *plugins* could do, if they
like. They would still be told about TRANSPORT_STOP, of course, in
case they actually *want* to stop.
Tim Hockin wrote:
I think he meant "start of beat" and that kind of stuff, rather.
("isolde stirbt" would be a change of a string Control of some weird
plugin. ;-)
Ok. So how does a plugin know about musical
milestones, then?
Suppose it wants to lock onto a beat edge. I agree that TICKS
events are not needed, since if you know the sample rate (you do)
and you know the tempo (you can), then you can extrapolate a
tick-width. The tick edge is the trick. Or do we not worry
about it and assume that the user will start things at the proper
edge, and plugins will just need numbers of tick-widths?
i usually intersect the beat interval giving function with
the current processing cycle. i don't quite know what you
mean by milestones, it does sound like meta-information to
me (like "begin song part A here", "isolde stirbt", etc). I don't get
what you were saying about virtual time. Let me try:
frame-count is a global rolling counter. It never stops, unless
the host has a special 'off' mode. Ticks is a mucial counter
starting at some point, 0, that represents the timeline
(track/song/whatever). It can jump forward (12, 13, 165) or
backward (165, 166, 1) or loop, or pause. If it is paused or
stopped, the frame-counter is still going. Since plugins just
track 'ticks' by that, they still work.
Is that correct?
it's much simpler. imagine the transport time rolling on
through a 'stop', and some plugins handling things a bit
differently.
That's what I don't quite like. I'd prefer if plugins that don't care
could... well, just not care! :-)
With audio timestamps, that would be very easy, and I'm still failing
to see how there can be any complications in dealing with musical
time, just because you stamp events with something else, that has a
known relation to musical time for every sample of the current block.
1. There can never be a question about when an event
is meant to be applied. (You will process for N
sample frames, or there will be trash in the audio.
Likewise with events - and they're based on audio
time.)
2. 1 applies to the sequencer as well - so it will
*have* to have decided how to map musical time to
audio time, before it lets other plugins run. There
is a known, fixed relation for every sample in the
block.
3. Given 1 and 2, you can always translate an event
that you're supposed to process, into musical time,
with sample accurate timing.
4. If you want to manipulate timing of events in
relation to musical time, you will have to consider
the fact that no one knows the exact mapping of
musical time to audio time in future blocks.
5. Given 1 and 4, you can wait until the musical time
you're interested in is within the current block.
Not until then can you make a final and correct
decision.
//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 ---