[gmpi] Re: New Reqs 3.8 - Events

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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: