[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 14:26:03 -0800

On Sun, Jan 02, 2005 at 04:15:37AM -0800, Crudesoft wrote:
> > Agreed completely - horribly inneficient.  We could
> 
> Most of the knobs are not used at all and hence do not
> generate any output at all. Some of the knobs are used
> and generate output. The used knobs are most of the
> time idle. In a stream-based control scheme idle knobs
> just fill a buffer with a constant and consumers only
> have to check this buffer for changes. That is not
> efficient, but then again, there is no optimal
> solution. 

There _IS_ an optimal solution - send exactly as much data as you need to
exactly represent a change.  No more. No less.  Filling buffers with a
constant every process loop is terribly wasteful.  It conveys no useful
information and just wastes memory.

At a minimum, you could devise a hybrid system that sent an event
indicating a change in the input buffer for a knob.  Then you can have
sample-accurate "events" which indicate the start/end of a set of values.

Now, you also spoke of a per-parameter sample rate.  Each receiver
(parameter) needs to be able to down- or up-sample the control stream as
it sees fit.  But if you have a single sender sending to multiple
receivers, you'll have to resample it in the host.  In fact, whenever you
have a sender at one sample rate and a receiver at another sample rate,
you'll have to resample.

> I doubt that using events for continuous controls will
> be much more efficient than streaming controls. As
> long  as the event frequency stays low all may be
> well, but what if the event frequency goes up? What if

With events, the frequency can go up to audio-rate.  It gets less
efficient as the rate increases, but I think that is the edge case.
That's also why we left room in the reqs for audio-rate controls.

> Events are not more precise than streams. To get good

We never said they were.  We said they were a reasonable trade-off for the
inefficiency of control streams.  Control streams at multiple sample rates
is no less complex than events, just different.  Control streams at a
fixed sample rate becomes a hard limit.

We could have (come spec time) a per-graph control-rate, which all
controls in a graph would use.

> Rendering at the
> source assures that all consumers will use the same
> control function without room for interpretation.
> Rendering at the destination takes time too and
> duplicate (and up) rendering even more.

Except that rendering at the source assumes that all receivers use the
same control rate.  That's not a safe assumption, yet.  Rendering at the
receiver means that every receiver gets exactlyt what it can handle.
Ramp events allow you to descripe a change in VERY exact details, and let
the receiver handle it as it can.

> - Standards should be as clear and simple to use as
> possible. Do not let exceptions enter a standard
> unless there is really no other way. Exceptions

Show me where we have exceptions?  We've tried very hard to make GMPI
consistent, so far.  There is even an argument to *only* have ramp events,
and get rid of point events (a point is a ramp with duration 0).

> - Hardware limitations of todays computers should not

hardware will probably never be "fast enough". If I had 2x the CPU power
today, I'd double my sample rate.  If I had 2x that, I'd use beefier
plugins. Ad Infinitum.  One of the goals of GMPI is to be efficient.

That said, I could probably live with a scheme of "control-rate" buffers
of control data.  They can be started and ended by some notification, and
ignored otherwise.  They can be sanitized by guaranteeing that all
controls within a (sub-)graph are consistently sampled.  Plugins will
still do smoothing internally.  Nothing will really change from the way
things are done today.

Or I could live with a scheme of all ramp events.

It's spec material.

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

  1. Home
  2. gmpi
  3. Archive
  4. 01-2005