[gmpi] Re: Topic 6: Time representation
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 29 Apr 2003 15:11:03 -0400
>>>
There can still be a temp map of sorts for the block you're about to
process. Just like there's a deadline for changing anything in the
audio output, there's a deadline for changing anything that may
affect the operation of plugins during a block cycle. The tempo map
may well change it's relation to audio time before the *next* block,
but that's no different from the situation with a sequencer running
on external sync.
<<<
Most sequencers allow tempo changes to occur arbitrarily dense, possibly
even as dense as one tempo change every MIDI tick. (Imagine an accelerando
or deccelerando.)
In this scenario, if the processing frame is small but not tiny (say 5 msec
for arguments sake) it's possible that a single audio processing frame will
encompass more than 1 tempo. This means that any model which assumes each
audio frame is a single tempo will fall short, unless the host knows to
subdivide processing frames at tempo change boundaries.
Call me an optimist, but I want my plugins to believe there is a future.<g>
Imagine a GMPI version (actually today in OPT version 1), where a plugin can
pull data from anywhere out of a project's timeline at any time. Giving
plugins access to future data and/or a birds-eye view of a song can be very
powerful.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
