Ben wrote:
Mike Berry wrote:
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:
I do not believe this is at odds with the Actor concept. The host still calls a "set" function which is then mediated by the logic internal to the plugin, within the same thread. The only difference is that the host does not call a specific "actor" function on every plugin. and it is 100% optional whether a plugin wants to subscribe to it's (or any other) parameters.
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.
It is more accurate to say that the published parameter (not the plugin itself) is the ultimate holder of the parameter state. Except in special cases (an enum, for example), the plugin will never "limit" a parameter value. The unlimited value must be maintained to allow for offsets between linked parameters. The GUI and the plugin DSP must implement any limiting.
I don't know why there is a requirement to avoid the listener/broadcaster model just because the VST model has some shortfalls. The console that we just shipped to Universal Studios uses this method, and it has over 81,000(!) simultaneously automatable parameters and 60+ threads of execution. ( the console itelf is almost 40 feet long .... come by NAB next week if you'd like to see a smaller version of it... )
Of course, this is all implementation details. As far as requirements for inter-parameter linkages, I would suggest: 1) A "parameter" object (or similar concept) must exist for any value that is required to define a plugin's state.
2) The "parameter object" is the ultimate holder of the parameter value and is generally not clamped to a valid range. GUI and DSP code may keep mirror images of this value which are clamped to valid values.
3) Any changes to a parameter must be broadcast to any subscribers that wish to monitor this parameter. This may include the plugin itself (to handle linked parameters,etc), the host (for user-created links), DSP, GUI, hardware UI, network layers, save/recall/undo mechanisms, etc.
I guess what I'm advocating is that there need be no inherent support for parameter links in GMPI .. ony that a mechanism is available for hosts or plugins to implement (linking/randomization/morphing) if they wish.
-- 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
