plus, let's be honnest, in practice, only a fraction of a plugin's
parameters are zipper-noise-free.
A plugin can have thousands of parameters. Ramping them all can be
impossible, CPU-wise, for some of them.
More, there are filters parameters you just can't ramp, practically. You
just can't recompute the coefficients for each sample.
Usually a plugin implements its own ramping for parameters that make sense
to be automated.
Now, at rendering time, nothing prevents a host from rendering in 1 sample
blocks, and modify the parameters in-between.
So you can talk all you want about ramped parameters, but you'll have to
consider that for lots of parameters it can't & won't be supported. So
better not make this an absolute requirement, it'd be an utopia.
To me the fact that events are time-stamped allows the host to adjust its
'parameter rate', to have let's say a 2ms block rate realtime, and as low as
1 sample for rendering. Without the need for ramping.
On Sun, Jan 09, 2005 at 08:10:13AM +1300, Jeff McClintock wrote:It's important to note that current plugins ramp between controller events themselves. It is no more or less practical for the host to perform that same function. The payback is, there are thousands of plugins, yet fewer hosts.
I have to agree with Didier on this, though. The host can't know what is an appropriate ramp for every change for every parameter. A change from 0 to 100 may need a much longer ramp than a change from 0 to 10. Or it might be exactly the opposite. The host can't know this.
When dealing with realtime inputs, you have to send them exactly as you
get them, or the host ends up coloring the control stream. Sometimes that
is OK, for example FL Studio has a 'smoothing' knob for each control signal
which adds some slew. That's a known coloring and it can be turned off.
Plugins have to do these ramps internally if they want to guarantee freedom from things like zipper noise. The key is not that they do they internally, but that they do them CONSISTENTLY.
That is to say: if I change the value from 0 to 100 today, and I play back the automation tomorrow, it better render exactly the same result. As long as that much is true, it doesn't really matter if I choose to make my A parameter ramp for 1 ms on any change and my B parameter ramp for 1 ms per 6 dB change. It becomes part of the character of the plugin.
Yes, currently Host sends 'point' values, plugins ramp internally. Something of a 'hack' as plugin has no knowledge of the automation source (or more importantly, no knowledge of the optimum smoothing rate). Plugin is forced to smooth based on a 'typical' controller rate.
If the host *knows* a ramp is happening, then it should use that. Specifically, if a user has asked for a smooth ramp (or has turned on host MIDI smoothing), then use a ramp.
However, if I record MIDI input and I choose NOT to smooth it at the host (or if I am playing live) I really *do* want all my plugins to de-noise the control.
And realistically, many plugins are still going to have to do this, because the developers want consistent quality.
This is not radical, VST plugins *already* do ramping themselves. Shifting that responsibility to the host-side makes no difference. We lose nothing.
Except the intimate knowledge of how each parameter needs to be handled. Normally I'm all for moving responsibility to the host. You should all know that by now. But this is one place where I think plugins still have to do some work. Not all plugins will want to, but some will.
Tim
---------------------------------------------------------------------- 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
