[gmpi] Re: gmpi Digest V2 #6
- From: jeffmcc@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 09 Jan 2005 09:18:25 +1300
>
>
> 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.
>
>
>
>
> ----- Original Message -----
> From: "Tim Hockin" <thockin@xxxxxxxxxx>
> To: <gmpi@xxxxxxxxxxxxx>
> Sent: Saturday, January 08, 2005 8:31 PM
> Subject: [gmpi] Re: gmpi Digest V2 #6
>
>
> > 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
>
----------------------------------------------------------------------
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:
