[gmpi] 3.11 topic: Parameter Actors

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sat, 10 Apr 2004 09:18:39 -0600

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

Other related posts: