[gmpi] Re: gmpi Digest V1 #65 topic: Inter-parameter linkages
- From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 15 Apr 2004 01:33:36 +0200
On Wednesday, April 14, 2004 5:42 AM [GMT+1=CET],
Paul Davis <xxxpaul@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> the diagram above is one way, reflecting the fact that LADSPA splits
> ports into input and output ports. but the basic idea that the act of
> setting a parameter is nothing more than sending a request to the
> plugin and waiting to see if anything happens is, i think, a key
> one.
I fully agree, that's why I started this whole discussion: because I've
needed to go trough this in my plugin for the min/max/locked sliders...
"1. external controller sends control change request to plugin (user tweaks
GUI, moves fader, ...)
2. plugin handles the request and changes internal states
3. plugin in some way lets the external controller know what it did with the
requested control value change (GUI feedback, motorized faders, force
feedback, whatever, ...) and potentially also other parameters that depend
the one for which a change was requested"
The difference is that everything now passes through the host: no direct UI
<--> core communication, if I get it right. If so, that's fine with me.
To compare what I'm doing with the new proposal:
"The way I am handling this in a VST plugin of mine, is by calling a
setParameter function of my dsp core code with an extra argument that can
be used to return other parameters that might have changed during the dsp
setParameter call:
setParameter(inParamIndex,inParamValue,&outListOfChangedParameters)
The code calling the dsp core (in my case the VST effect class around the
dsp core, called by the host) then checks the list (might be empty) of
returned parameters that have changed and uses getParameter on the dsp core
to obtain their eventual value and propagate this to the outside world (the
environment the plugin "lives in", probably the host)."
It seems now that what I am doing in my plugin core in response to a
setParameter from the host looks very much like what is now being proposed
to be done in an actor, so I'm surely fine with this way of handling
parameter changes (or should we say parameter change *requests*?).
> i don't think it would work that way. the actor would merely note that
> it was morphing, the start and end values and the start time
> (frame). the actor has to be "process()'ed" in just the same way as
> the plugin.
OK. To compare (I need this to keep me sane) with how I've seen morphing
being done:
"As far as I've seen, morphing on preset switching is handled by keeping two
values for each parameter in the DSP of a plugin: a target value, and the
current value. When a new process call is made (or multiple times within a
single process call for a whole block) the parameter value is then updated
towards the target value (usually depending on some speed and/or overshoot
setting and the current difference between the current and target value).
Updates that generate the new parameter values are driven from the DSP code
during a process call so that it also works without a UI."
So I guess that the difference here is that the actor also needs the start
value and start time. The fact that it has to be "processed" is the same,
except that I thought maybe doing this multiple times per block would be
sufficient (per sample more accurate of course). OK, sounds fine to me.
> in fact, i am opposed to them being separate entities. the
> actor is an API detail of a plugin, not a distinct object.
I think you're right: it might be a separate concept, but should probably be
contained in the plugin itself.
The processing of the actor would solve the morphing use case I proposed.
Just to re-iterate and make sure it fits:
"[While it springs to my mind: one other use case where updates from the dsp
code to a UI are needed is the following:
More and more plugins nowadays allow for automated ways of changing
parameters (I don't mean host-controlled automation here). One of these
things is morphing of parameters from one setting to another (for example:
switching presets will morph from one preset to another, or pressing a
"mutate" button will gradually change parameters to new, nearby but yet
different settings). Now, this morphing is done from within the core code,
and I personally (and I think all my users) would very much like to see the
current parameter states reflected in the UI while they are changing. This
calls for dsp-->UI notification.]"
Where "dsp" (or "core") in my terms here means "actor + dsp" in the new
terms.
dsp <-> UI notification now goes through the host though.
I'm fine with that.
Koen
----------------------------------------------------------------------
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:
