[gmpi] Re: 3.11 topic: Inter-parameter linkages
- From: "gogins@xxxxxxxxxxxx" <gogins@xxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 12 Apr 2004 14:57:04 -0400
OK, I see your point.
But how does a container plugin receive and display or handle parameter
changes performed by its contained plugins?
Original Message:
-----------------
From: Mike Berry mberry@xxxxxxxxx
Date: Mon, 12 Apr 2004 10:41:11 -0600
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: 3.11 topic: Inter-parameter linkages
gogins@xxxxxxxxxxxx wrote:
> This sounds like a good idea.
>
> Original Message:
> -----------------
> From: Ben ben@xxxxxxx
> Date: Mon, 12 Apr 2004 08:56:07 -0500 CDT
> To: gmpi@xxxxxxxxxxxxx
> Subject: [gmpi] Re: 3.11 topic: Inter-parameter linkages
>
>
> I think Jeff is on the right track with the "Actors" concept.
>
> I would suggest the following mechanism:
>
> When a plugin is instantiated, it publishes data "parameters" which are
> globally accesible. Parameters have a value that can be read/written to.
> They also have a mechanism for subscribing to them. Whenever a
parameter's
> value is written to, it broadcasts a message to all it's subscribers.
>
> Plugins may themselves subscribe to parameters (theirs or anybody else's
..
> for example a tempo-synched delay might subscribe to the host "tempo"
> parameter). This supports Jeff's "Actors" concept. The host changes a
> parameter, and the plugin has a chance to react to the change. All the
> code is included in the plugin instance ... the host does not have to call
> any special functions.
>
Actually, this is at odds with the Actor concept. This is a standard
broadcaster/listener system, which is exactly what is the problem with
VST. Here is the problem:
In your model, the plugin is the ultimate holder of the parameter
state. The host can send a parameter change, but then the plugin can
change it and send out a message. This means that the host has to obey
the value determined by the plugin, but it is also trying to set the
value. The broadcaster system also has threading issues. If it is an
async broadcast, then you have the host unable to complete an undoable
action without waiting for possible messages. If it is synchronous, then
you have many listeners (like GUI) which should not be getting process
thread calls getting them.
Finally, it requires a really ugly host-side mechanism/hack which
stores a completely parallel version of the current values of the
parameters, and tries vainly to keep them in sync with the values that
the plugin thinks are current. I know exactly how ugly and bug-ridden
this design is because I have written host support for VST
(setParameterAutomated is simply a variation on the model you are
proposing - the plugin broadcasts a parameter change using
setParameterAutomated, but relies on the host to dispatch to all
listeners instead of maintain the listener list in the plugin. Arguably,
setParameterAutomated is actually a better design than having all of the
listeners register directly with the plugin, because it moves one
complex piece of code from the plugin, where it would be repeated in
every plug (with subtle, app-destroying, variations) to the host).
The actor model gives the actor plugin a chance to make modifications
to an event before it happens, but in a synchronous and completely
contained manner. The host is the only broadcaster in the system, and
the DSP is simply a parameter sink. The current value of a parameter is
always maintained by the host, which gets away from one of the great
problems with VST, which is that the plugin is the ultimate authority on
the current state of a parameter.
The most important thing in my mind is that the DSP not be permitted to
set parameter values, ever. There should not even be methods for the
host to query for parameter values. This should be true whether or not
the actor is a separate plugin or simply separate calls on the sample
binary. We must have a wall between parameter logic and signal processing.
--
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
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
----------------------------------------------------------------------
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:
