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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Mon, 3 Jan 2005 08:19:19 -0800

On Mon, Jan 03, 2005 at 03:36:50AM -0800, Crudesoft wrote:
> > 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).
> 
> Ramp events are the exception. How do you implement
> ramp events for more or less randomly changing knobs?

I think you're trumping up "randomly moving knobs".  Look. There are 3
main types of knob movements I can see:

1. Human initiiated.  These come in from a GUI or from MIDI or something
like that.  They may be random at a macroscopic level, say over the course
of a second.  But over the course of 25 ms, they are NOT random.  They are
mostly linear.  Why?  Because humans are slow.  Keep in mind also that
MIDI is not capable of sampling a control signal at 44k.

2. Automated.  These *could* be random on the microscopic level, but I'd
be really really surprised if any majority of users did this.  I could be
wrong, but I don;t think so.

3. Plugin controlled.  Think LFO.  Here's a case where random could
happen.  But I think again that a signal that is random at a sub-buffer
level is going to be very marginally useful.

> For me it is simply not a natural approach. Events may

I agree that ramps are not a natural way to think of things - this is my
biggest problm with it it and my biggest attraction to audio-rate
controls.  But it's not an arument by itself.

> Events may look good on paper but I think they will be
> a pain to implement. IMHO control signals are like

Just for the record - events are how most every DAW software works
*today*.

> Although control signals are often rather low
> frequency signals this is not necessarily always true
> and their bandwidth should not be limited by
> specification. Audio rate events? I don't think so.

They have to be audio rate in order to be sample accurate.  Unless you
have another solution.  But you have been presented with this and not
solved it.

> modules as a result. Efficiency issues of today should
> not be part of a standard that wants to be a standard
> of tomorrow. 

Ahh, so you mean that tomorrow we'll all have enough disk and memory
bandwidth to not worry about it?  Don't think so.

> Let me put it this way:
> Knobs are signals, period. Treat them that way.

Let me put it this way:  You have not made a strong enough case.  Further,
we're finishing *requirements* now.  If you feel very strongly about this,
I really invite you to get on the implementation team, make a solid case,
show a proof-of-concept implementation, and convince us/them.  I've
already said I'm willing to listen.  I've even argued your position,
somewhat.

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