Been reading this thread and wanted to offer a thought. Really what
we've been saying is two things: 1) in some plugs, some parameters
can only be updated just so fast -- making control event changes
faster than some max doesn't result in any better control because the
plug only samples it at that rate, and are therefore wasteful; and 2)
some plugs may not want to have to implement ramping for some or all
of their controls -- maybe because the author didn't see the need, or
maybe because they just consider it too much trouble.
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.
Seems a little simpler. This way an event sender doesn't have to
query for is-ramping-supported on a per-plug (many) basis, just on a
per-host (global) basis.
-- C
---------------------------------------------------------------------- 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
