[gmpi] Re: ramps vs audio-rate controls

On Fri, Jan 16, 2004 at 09:17:15AM -0700, Mike Berry wrote:
> >No, "audio rate controls" effectively means you use audio streams 
> >instead of function call or event driven controls. Everything's 
> >driven by buffers of audio rate data. Controls are just a lot more 
> >similar to audio ports.

>       I think audio rate controls would be very problematic. In my 
> experience, most controls most of the time are not changing. How often 
> do you use a filter sweep as opposed to a fixed frequency? So an audio 
> rate control would be carrying huge amounts of redundant data. If you 
> then offer an optimization for unchanging controls, you are basically 
> back to the events model.
>       Also, there is nothing in the events model which says that you can't 
> send events at audio rate.

Sending events at audio rate is severely wasteful.  What if we made a third
type of event:
  point-value: at the timestamp jump to this value
  ramped: at the timestamp ramp to this value over this duration
  audio-rate: at the timestamp use this buffer of audio-rate values over
     this duration

Audio-rate events give you the power of audio-rate controls, without having
to keep the audio-rate input populated wastefully.  They also give you the
power to do complex ramp shapes with no plugin support.

In fact, all we REALLY need is variable-length audio-rate events to do
ramping and point values (though wasteful).  Maybe all we REALLY need is
point value and audio-rate events.  Ramps are just calculated audio-rate
events.  Plugins may decimate the audio-rate inputs, if they need to.  It
solves the "What happens to a ramp at the end of the buffer?" issue.  It
solves the "What if I want a spline ramp?" issue.  It solves the "I need to
send a lot of events really quickly, but that wastes CPU and memory on many
events." issue.

We're supposed to be forward thinking, right?



Thoughts?


----------------------------------------------------------------------
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: