[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
> 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
> 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: