> this i can agree with. but in this case, i don't understand what the > actor is for. > LADSPA: plugins do not own the memory corresponding to their > parameters. they provide the host with information on how many > parameters they have (and theoretically, what kind), and the host allocates the memory... Agree totally, Parameter values are stored in the host. The host may provide the user a simple interface for setting parameters ( a host-provided GUI ). > the downside to this model (and its not much of a downside) is that > the plugin has to provide *all* the necessary information about the > parameter to the host. > if the plugin *can* provide the information, however, this model is > very simple, it localizes complex code in the host where it should be, > and it is clear that the host should be the "broadcaster" for > parameter changes. Actor, enter stage left..... Your plugin might have rules like: * "volume parameter is limited to 10.0 or less" .. * "Left Chan Volume is linked to Right Chan Volume"... * "filter resonance may not exceed log(filter_cuttoff) / PI" The plugin wants to enforce those rules. The simpler rules can be enforced with hints e.g. "volume parameter has a valid range of 0 to 10", but the more complex rules are difficult. It would be nice if the plugin could reject invalid parameter values (parameter clipping), or even update one parameter in response to another (linked or ganged parameters). The problem is: Parameter changes are delivered to the DSP as timestamped events. All parameter changes for a timeslice are delivered in advance. A parameter may change several times during a timeslice. In other words, the communication from Parameter->DSP is one-way, and the events are qued slightly in advance. This makes it very difficult for the DSP to influence it's input parameters. The easy answer: The plugin could simply silently enforce these rules in the DSP. If the user set the volume to 11, the DSP simply ignores that (uses a value of 10). The nicer answer: We give the plugin a 'hook' into the parameter-setting process. i.e. When the user attempts to move the Volume slider to 11, the parameter change is sent synchronously (immediately) via the plugin's 'actor'... [Host GUI]<---->[Actor]<---->[Parameter]----->[DSP] The actor is inside the MVC notification loop. It has a very simple interface. It deals only with parameter changes. Any attempt to set the parameter goes via the Actor. This includes automation-tracks, Host-Provided-GUI, MIDI CC's etc. The actor absolutely enforces any rules on that parameter, those rules can be as simple or complex as the plugin writer desires. Advantages: -All 'GUI's are subject to the parameter rules. - Any parameter can be clipped/validated. -All GUIs reflect the *actual* parameter value the DSP is using. -Any arbitrary linking/ganging is allowed (and even reflected in host-provided GUI) - The DSP has all it's parameter validation done in advance. - The Actor is in a position to randomise the parameters. These kind of tasks are usually part of a Custom GUI. However the Actor makes them available in non-GUI hosts, or hosts that present their own parameter-setting interface. I image the Actor's interface is extremely simple. The Host passes parameter changes to the Actor, The Actor modifies the value if needed, and sends it to the host's parameter memory. The Actor is entirely optional. The Actor is entirely separate from the DSP. It is not subject to the same constraints as the DSP, that's why it's a seperate entity. Best Regards, Jeff ----- Original Message ----- From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx> To: <gmpi@xxxxxxxxxxxxx> Sent: Wednesday, April 14, 2004 5:11 AM Subject: [gmpi] Re: gmpi Digest V1 #65 topic: Inter-parameter linkages > > I'm not saying that we should avoid the broadcaster/listener model. I'm > >saying that the DSP of the plugin should not be the broadcaster, or the > >holder of parameter objects. The parameter object has to be in the host, > >because only the host has access to all of the information necessary. > > this i can agree with. but in this case, i don't understand what the > actor is for. > > as an example of a system that works something like this, look at > LADSPA: plugins do not own the memory corresponding to their > parameters. they provide the host with information on how many > parameters they have (and theoretically, what kind; currently, all > LADSPA parameters are floats), and the host allocates the memory and > tells the plugin the address. > > consequently, it is abundantly clear in such a case that the host > controls the parameters. of course, for many plugins, the parameter > owned by the host is just an external reference point for the internal> if the plugin *can* provide the information, however, this model is > very simple, it localizes complex code in the host where it should be, > and it is clear that the host should be the "broadcaster" for > parameter changes. > variable used - the plugin might not even be on the same CPU. > > the downside to this model (and its not much of a downside) is that > the plugin has to provide *all* the necessary information about the > parameter to the host. try building a generic GUI for a VST plugin, > and you'll realize that if the plugin doesn't respond to > effGetParameterInfo, you're hosed. you don't know suitable step sizes, > you don't know whether its a bi- or tri-state variable, etc. > > > --p > > ---------------------------------------------------------------------- > 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 > >
Attachment:
GMPI_Parameters3.gif
Description: GIF image
