[gmpi] Re: Reqs 3.8 Events - ramped events
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 7 Jan 2004 17:47:11 +0000
On Wed, Jan 07, 2004 at 06:16:39PM +0100, David Olofson wrote:
> I see, but I don't think it's the right solution for declicking
> control (dis)connections. It only works in special cases with certain
> kinds of plugins.
>
> For example, if you abruptly change a parameter of a reverb plugin,
> the resulting click could be heard reverberating in the audio output
> for ages. Xfading the audio won't make much of a difference.
Ah, I didnt follow you meant control disconnections, I wouldn't think
thats an issue.
> With <start, delta> events, the long term error buildup is eliminated,
> but instead, you risk getting a small jump in the control value
> whenever a ramp event is received. This may not be an issue with
> float or double control, but I learned the hard way that it *is* an
> issue with fixed point controls. (Unless they have much more than
> twice the number of bits of an audio sample, at least. 32:32 controls
> for 32 bit audio with 0 dB at 16 bits? I don't think so...)
OK, but the drift is very low, and its going to be floating point so I
dont think this will be an issue.
> Either way, you'll need to deal with the potential error buildup one
> way or another, so you can't avoid generating at least absolute
> values and at least one of deltas, durations and whatever other
> representations we can dream up.
Yes, each event needs to reset one end.
> > Not if you pass deltas, then its not a special case.
>
> It just becomes a special case on the sender side instead.
Yes, but I write plugins ;) More to the point there will eb more plugins
than hosts, so it makes sens to have the special cases on the host side
IMHO.
> I don't see how grabbing 'target' from <target, duration> is more
> work. :-)
Its not, but its out of sync. If you want to be close to the real curve
yhou need to remeber the target until the duration is up.
> Right - but that means we need to change the ramping events and
> semantics to support integer/fixed point platforms. I don't see the
> point, when we can just use <target, duration> events and be done
> with it.
Do integer platforms want ramps?
> > A lot of the time the plugin will be applying its own smoothing to
> > the result of the linear ramp, and I dont see this as an issue
> > anyway. Why would it be that innacurate?
>
> Try fixed point controls. :-)
Noone has suggested supporting fixedpoint. I dont know of any sytems that
have native fixedpoint support and are capable of loading DLL style
plugins.
> Either way, as I pointed out in another mail, the whole point with
> ramped events is to avoid destructively brutal smoothing. Linear
> ramping is bad enough as it is, but at least it doesn't inherently
> generate practically random transients between sections.
Well, it does, but thier less work to smooth :)
- Steve
----------------------------------------------------------------------
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:
