I've been thinking about all this for a while (while I was travelling)
so let me suggest what I think is a different and workable approach:
We have always been thinking of only two levels for a plugin: GUI and
DSP. I think, however, that we may have identified a need for an
optional third, which I am calling an Actor. So let me set the ground rules.
In the DSP, no parameter linkages are allowed. All parameters must be
able to be set independently by the host, as during automation. The DSP
has no method to tell the host that a parameter has changed - it is a
sink only.
A DSP plugin may declare that it has a parameter actor. If so, the host
can route non-automation parameter changes through the actor. The actor
is not able to call the DSP. All the actor does is return a set of
parameter values in response to a single (or multiple) parameter input.
These parameter values are then sent by the host to the DSP.
Lets cover the use cases:
- Two linked parameters. When the host sends a value for one of the
parameters, the actor returns value events for both parameters to keep
them in sync.
- Morphing. The host sends the morph value to the actor, which returns
the entire set of parameter value events.
- Ganging mono plugins. A single actor is used to generate the parameter
values, which are then sent to all copies of the mono DSP.
- Randomization. The actor creates the random values once when called
with a parameter.
This also solves the host side issues. The host can now perform undo,
because it knows all of the parameter values that changed. The host can
provide deterministic automation, because the random values are only
calculated once in the call to the actor. You can't ever get into a
fight between the DSP and the host over the current value of a parameter
- the host is always correct. And the broadcaster/listener mechanism for
UI notification is completely handled by the host. The DSP is simply a
listener like everyone else (which simplifies the DSP). Plus, even
plugins with generic UI can do morphing and randomization using an actor.
I don't know if the actor is a separate plugin or linked with the DSP.
I like having it totally separate, so that there is no temptation for
the plugin writer to make illegal linkages between the actor and DSP. It
also opens the possiblity of multiple actors for a single DSP, so if you
can up with a cool morphing algorithm for someone else's filter bank,
you could install it. You could also cascade the actors for a single
DSP, so you pass through one morph, followed by two different randomizers.
Thoughts?
-- Mike Berry Adobe Systems
---------------------------------------------------------------------- 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