[gmpi] Re: Topic 6: Time representation
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 29 Apr 2003 20:23:50 -0400
>>>
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?
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.
----------------------------------------------------------------------
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:
