[gmpi] Re: Topic 6: Time representation

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 29 Apr 2003 18:23:16 -0700

 >>>
     gmpi::setParamRampTarget( myParamID, myRampTarget, myRampShape );
That's not too horrible.  Then we can add new shapes in future -if-
we discover the need down the road.
<<<

To define a ramp you also need the ramp duration, right?

Right. But I was concentrating on the curve shape, and also only thinking about the way param interpolation would look to the plug-in, not to the host as it tries to ramp things across, like, seconds etc. And I was also assuming -- probably wrongly -- that it would be enough to only have one interpolation period per parameter per timeslice, and that a reasonable default duration would be the whole timeslice. So you have a param value at the start of the timeslice, a target value to hit at the end of the timeslice, and a curve shape. I suppose if you wanted different start and/or endpoints, you could also have setParamRampStart( myParamID, myStartSampleIndex ) and setParamRampEnd( myParamID, myEndSampleIndex ) -- but again, this only gives you one ramp per timeslice, maybe that's not enough...

Forget I said anything... 8)


I had to deal with this problem in developing the DXi SDK.  On the one hand,
you have DirectX automation which is powerful but kind of difficult to work
with.  On the other hand, you have plugins that have DSP which are being
cross-purposed for DirectX and VST, where the VST version doesn't get the
shape info that the DirectX version would.

The way I addressed this inconsistency was to allow the plugin to get the
current parameter value for the current processing frame, plus additional
methods to get "deltas" for the current value.  For example, suppose you are
ramping volume linearly from 0 to 1 over 1000 samples.  At sample 500 the
gain value is 0.5 and the delta is 0.001.  (DXi actually does second order
shapes, so there are 2 deltas.)

The point is that this approach allows plugins to get just a plain param
value if they need it, or fancier ramping information if they want to try
that too.

So DXi has a myParamVal = getUnrampedParamVal( myParamID ), a myParamVal = getRampedParamVal( myParamID, mySampleTime ), and a myParamVal = getParamRampDelta( myParamID, mySampleTime )? That works, I get it.

I guess I was thinking we might let the plug's automation channel tell the host how it wants the ramping to work for each parameter with methods like the ones I listed above (like once at the start of each timeslice, or maybe persistently across timeslices), and have the plug always call a single myParamVal = getParameterValue( myParamID, mySampleTime ) every time it cared about getting a new value, however frequently or infrequently the plug needs that. Then the plug's gmpi::process() code wouldn't need to care about whether the param is ramped or not; if the param is getting ramped then the plug gets the instantaneous ramped value, or if the param isn't being ramped then the host skips the incremental update math and the plug always gets the value as of the start of the timeslice. Though we could probably also define the shorter signature myParamVal = getParameterValue( myParamID ) to just return the unramped, start-of-timeslice value; that'd save the plug programmer from having to get his hands on the sample time.

-- Chris

P.S. Good as this discussion is, this really is getting OT for Topic 6. File under 'Automation'?

----------------------------------------------------------------------
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. 04-2003