Hello,
Question: do certain classes of shape break (or become too mathematically complex to reasonably describe as parameter events) if you try and split them up over multiple render blocks?
>Question: is there a need to express this type of >event in musical time, or is it safe to assume that we >can use linear time and reset the parameter's required >state and transition status if the song playback is >nonlinear (i.e. if the song loops back)?
Question: assuming we choose to support timestamped parameter events, is there even a need for "fades with duration" and "parameter ramps" as part of the plugin API? Obviously it's a nice thing to have, but it seems like
Thanks, George.
On Tue, 29 Apr 2003 RonKuper@xxxxxxxxxxxx wrote:
Please, no... this is the worst and most difficult part of DXi to implement <<<
I wasn't suggesting we emulate or repeat the DXi model. Events with durations are unavoidable IMO. It's not only note events. It could also be "shape events", segments of an evolving parameter change such as a volume increase. These things exist in DirectX today. Not to assume we'll agree to make it the same in GMPI, but there are also benefits to both approaches.
Question: do certain classes of shape break (or become too mathematically complex to reasonably describe as parameter events) if you try and split them up over multiple render blocks?
i.e. if you want to express "smooth exponential fade from -6dB to 0dB over slices 13..27", is it problematic to break that down in to a series of smaller fades (sliced at block boundaries) that conform to the required curve and tell the plug what to do in "bite-size chunks"?
Question: is there a need to express this type of event in musical time, or is it safe to assume that we can use linear time and reset the parameter's required state and transition status if the song playback is nonlinear (i.e. if the song loops back)?
Question: assuming we choose to support timestamped parameter events, is there even a need for "fades with duration" and "parameter ramps" as part of the plugin API? Obviously it's a nice thing to have, but it seems like a fairly significant complication to the API on the plug-in implementation side for the sake of a few CPU cycles. What does everyone think on this?
Regards, Angus.
---------------------------------------------------------------------- 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
---------------------------------------------------------------------- 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
