[gmpi] Re: 3.9 Time Formats
- From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 17 Feb 2004 12:42:48 -0500
> Is there a host developer who would care to comment on this ?
If a host were designed such that tempo changes were first class events,
rendered on the sequencer timeline like any other event, then it's
trivial to allow a plugin to change the map on the fly.
For our apps, tempo changes are pretty deep. Anything that changes how
musical time converts between sample time is a non trivial change.
For example, we have a highly optimized disk I/O scheduling algorithm.
It determines *precisely* how much memory is needed for reading all
regions from all files in the project, without any waste. This is key
to maximizing our disk bandwidth and track count. This algorithm needs
to do calculation on sample start times and extents for the audio data
in the project. When you change the tempo, the memory requirements for
the I/O schedule may change.
Sure, we can deal with it if we need to... it's just code<g>. Sure,
it's host specific. But it's just one issue in our app. There are
others, and I suspect other hosts have similar types of issues to deal
with.
If a tempo change is a first class event, why not an audio region? Why
not let plugins change that audio that's played on the timeline
dynamically, by injecting new files to play into the host's sequence?
Because (I think we all recognize) that this amount of realtime
interaction crosses the line between what we understand to be "easy" on
the host side, and what's "hard." If you want a plugin to generate
audio, write a sampler.
By the same token, if you want a plugin to mess with tempo, maybe the
solution is to put it downstream from whatever data it hopes to munge?
----------------------------------------------------------------------
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:
