[gmpi] Re: GMPI reqs draft 1 (part 2) for review, paragraph 4.10

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 2 Jan 2005 16:35:41 -0800

On Mon, Jan 03, 2005 at 01:12:13PM +1300, jeffmcc@xxxxxxxxxx wrote:
> > It *can* work.  Is there any reason to prefer this over
> events+ramps?
> 
> No, events are better.
> 
>  Event based updates provide a fully variable sample rate.
> You can temporarily increase the rate to handle transients. 
> When the knob ain't moving, you use zero CPU/memory.
> 
> A fixed rate system is no less complicated, but less
> efficient, less accurate (unless you run it at the full
> sample rate, which makes having a "control-rate" redundant),
> and less flexible (you can't vary the rate without
> additional complexity).

To play devil's advocate:

- Assume control rate == sample rate, always.
- Send an event + length when new control data is present.  Plugins ignore
  their control buffers otherwise.

= When a knob isn't moving, you use zero CPU.
= When a knob is moving, you have exactly sample accurate events.
= It's simpler for senders to generate than ramp events.
= It's easier for plugins to receive than ramp events (no calculation).
= It's simpler on the API (no event structures for every data type).
= If plugins are done right, it gets more accurate as the sample rate
  increases.

I'm not saying I am for it or against it, just that it *can* be simple and
elegant, and it should be considered. :P

Tim

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