[gmpi] Re: Reqs 3.8 Events - ramped events
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 7 Jan 2004 19:29:03 +0100
On Wednesday 07 January 2004 18.47, Steve Harris wrote:
> 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.
Well, plugins could handle it (they should be informed of any
(dis)connections made), but it seems nicer to let the host define the
behavior globally. Somewhere in Preferences->Advanced Options of a
host:
Controls:
Connection/disconnection de-clicking: On/Off
After disconnection: Hold current value/Set default value
> > 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.
It's going to be floating point on platforms that can handle it, but
I'm still not sure whether that means all platforms that are of
interest to us.
> > 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 ;)
...but no plugins that have control outputs? ;-)
[...]
> > 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.
That's out of sync too, by the same amount - only in the other
direction. The closest single step solution is setting the value
after half the duration of the ramp.
> > 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?
Well, maybe not, if integer == low end. (As in games, consumer media
players and stuff.) Considering what some high end studios use, I
don't think that's a valid assumption, though.
> > > 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.
Well, I don't know what file formats they use, but most DSP farm based
solutions are fixed point, AFAIK.
That said, I'm not sure it's much point trying to support them anyway,
considering that unwillingness to opening up the system is one of the
major reasons why those DSPs and closed plugin standards are still
used.
> > 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 :)
Maybe. Depends on how you do the smoothing, I guess. (By first
generating the ramped signal and then filtering it, or by
transforming the ramps to something else first, for example.) I don't
have enough experience with that kind of code to say what the optimal
format would be, or even if there is such a thing.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
