[gmpi] Re: New Reqs 3.8 - Events
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 23 Dec 2003 23:59:04 +0100
On Tuesday 23 December 2003 23.15, gogins@xxxxxxxxxxxx wrote:
> My suggestion of one spline per buffer was ill considered, and I
> retract it. It would be better for the plugin to receive whatever
> control points affected the music time or continous controllers
> within scope of the buffer.
>
> However, I am sure that a representation of tempo maps that is more
> compressed than however many ramps it takes to achieve precision
> would be highly desirable -- especially for plugins that are
> actually processing music time, and not just following it.
Unless we're talking about destructive off-line edit plugins (ie
plugins that write data back into the host's tempo map), does it
really matter if plugins see the actual tempo map?
Yes, I realize that it's better to have the original data if you want
accurate results after processing - but what kind of accuracy do we
need, and how much complexity can we accept?
Also keep in mind that the more compressed (ie complex to parse) the
data is, the greater the risk of different plugins doing it slightly
differently.
I'm not even sure the kind of structures suitable for a typical tempo
map are suitable for real time processing - and that would have to be
the primary function of a musical time interface in a real time
streaming system, I think.
Either way, every tempo tracking plugin will need it's own internal
"tempo sequencer", or some host provided tools, to bring the tempo
map data to life locally. This is probably a lot more than your
average beat sync effect or synth plugin really needs to do the job.
Finally, if you have access the full timeline (as opposed to the
events for the current buffer), it's easy to start assuming that the
tempo map will not change over time, or to have your own ideas about
what happens if things change after you've looked at them. (Closely
related to the "events, pre-queueing and the future" stuff.) If the
tempo map manager (plugin, part of the host, or whatever) generates
events on a buffer-by-buffer basis, such decisions are made once, in
a single place.
> Therefore, whether it is some kind of spline or whatever, I suggest
> this should be a requirement: plugins have access to the actual
> tempo map data as used by hosts.
What I don't like about this kind of interface is that it sort of
dictates how hosts implement tempo maps. Granted, hosts can have
their own internal data, but then the interface becomes something
like a parallel database that must be kept in sync.
A more serious issue is that an interface like this makes it *really*
hard to insert tempo map processors between the tempo map and tempo
tracking plugins. All musical time conversion calls would have to go
through the chain of processors. Depending on the nature of the
processing and the details of the interface, the whole thing could
become really rather expensive, and more seriously, very
non-deterministic.
BTW, I think it's too restrictive to think of tempo maps as something
that must be managed by hosts. What about "dumb hosts", where tempo
maps and sequencers are plugins? You could turn a mixer host
application into a sequencer by just loading one or two plugins, for
example.
Thinking about it this way, it's also more obvious how and where you
would process tempo maps in a plugin network: Insert event processor
between tempo map manager and whatever plugins should receive the
processed tempo data. It's just real time streaming and processing of
structured data, like (any other) control data.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
