[gmpi] Re: Topic 6: Time representation
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 29 Apr 2003 14:20:23 -0400
>>>
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"?
<<<
I guess you could always do a piecewise linear approximation, but you would
need to decimate the curve into very tiny segments for it to be a good
approximation, especially if the change was dramatic.
I suppose you could also send shape events down with each processing frame,
providing as part of the shape event the start/end time, the shape, and the
current position of the processing frame within the shape. That way the
plugin doesn't need to cache shapes until they expire a la DirectX, yet it
can still faithfully render the shape as it was intended.
>>>
Question: is there a need to express this type of event in musical time,
<<<
You can have a MIDI only project which uses shapes to automate a controller
value. So if musical time winds up in the model, shapes would need to be
expressable that way.
>>>
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?
<<<
If you don't implement parameter ramps, then "dezippering" becomes optional.
If the host wants a volume change without clicks, and it sends a ramp to the
plugin, the plugin needs to perform the ramp. This is the kind of behavior
that can be tested for in a standard test harness to validate plugins for
spec conformance.
-----Original Message-----
From: Angus F. Hewlett [mailto:amulet@xxxxxxxxxxxxx]
Sent: Tuesday, April 29, 2003 2:10 PM
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: Topic 6: Time representation
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
Other related posts:
