[gmpi] Re: Reqs 3.8 Events - ramped events

  • From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 13 Jan 2004 12:49:20 +0000

On Mon, Jan 12, 2004 at 05:57:36 -0800, Tim Hockin wrote:
> On Mon, Jan 12, 2004 at 05:42:08PM -0800, Chris Grigg wrote:
> > So, what if each parameter (OK, the control that drives each 
> > parameter) publishes two pieces of info: the max update rate of 
> > whatever internal DSP parameter(s) it drives, and whether the control 
> > implements ramping (within the plug)?  This way, a) you get the 
> > possibility of allowing an ambitious host to implement ramping for 
> > any control of any plug (i.e. even if the plug itself doesn't 
> > implement it), and b) there's no risk of inefficiency from generating 
> > too many update events because you only generate them as often as 
> > needed.
> 
> I'm OK with something like this.  Plugins that don't want to handle ramping
> can get pseudo-ramped by the host.  Plugins that can handle it themselves
> will.  Is the max update rate needed?  It makes things obvious, I guess.
> Not sure.  What do others think?

I think its overcomplex (supprise ;). OK, there are some parameters which 
the plugin cant/wont update very often, inevitably users will want to 
connect them to LFOs or something equally inapropraite, but why stop them?

I dont like things like "oh, you cant connect that input to an LFO, 
because the plugin author didnt want you to do that". OK, so if you do 
connect an LFO to a "slow" control, the control sample rate will be 
low, but it may do something that the user really wanted.

As other people have pointed out the ramp/slope, is just a hint that
/might/ allow you to have better audio quality - its up to the plugin
wether it uses it or not.

The delay example is a bit of an extreme one, because the total delay 
length includes a reallocation (in that implementation - my delay lines
dont do that) and so is blantantly not a RT control - it possibly
shouldn't even be changeable while the plugin is running.

We did discuss non-RT controls IIRC, but I cant remember what we decided.
Was it just that they would be hinted to produce non-RT friendly behaviour
when changed?

- Steve

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