There is another possibility, which is really a blending of 1 and 3.
All plugins have a synchronous CreateControlEvent method. The host
passes in the Control change, or list of control changes, that should
occur simultaneously, and the plugin returns an event. The plugin does
not execute this event. This allows the plugin to implement linked
controls, control quantization, and anything else it wants. Because the
control changes does not occur here, the host can create events on any
schedule that it wants. The plugin must regard CreateControlEvent calls
as isolated - the returned event cannot depend on the current plugin
state or the previous requested event.
ControlEvents are then asynchronously posted to the plugin with a
timestamped execution time. Or, alternatively, they are passed as a list
when the Process() method is called. The plugin is only passed events
that it created (or copies), so it can disregard an event that does not
match its criteria.
Mike
Tim Hockin wrote:
1. external controller sends control change request to plugin (user tweaks GUI, moves fader, ...) 2. plugin handles the request and changes internal states 3. plugin in some way lets the external controller know what it did with the requested control value change (GUI feedback, motorized faders, force feedback, whatever, ...) and potentially also other parameters that depend on the one for which a change was requested For example: control value change request --> plugin changes the associated parameter, but also other depending parameters --> external controller needs to be notified of all state changes that are reflected in the controller
This is a topic we discussed some wrt XAP, too. A couple options, as I see it.
1) Every control change is synchronous and function-called - YUCK + allows control changes to fail or have return codes - still doesn't cleanly handle linked controls - a function call for every control change is heavy, as compared to events.
2) Every control change is an event. Events have 'return addresses'. Plugins can respond to events by sending failure messages or other control changes back out. + clean design - need to check every change for a failure + only need to respond to unusual cases (no return means success) - host does a lot of event shuttling - responses have a 1 timeslice latency
3) Communication is one-way and does not fail. If you send a control change within a control's bounds, it CAN NOT fail. Linked controls are the problem of a custom GUI. Plugins do not spontaneously change their own controls. - no generic way to do linked controls - no way to update HW for linked controls - linked controls require a custom GUI
XAP was/is leaning towards the #3 option. I don't really like it. I don't really like any of them. #2 seems most reasonable to me, but as soon as you add proxied plugins, DSP hardware, network links, etc. you end up with potentially LONG return trips.
Tim
---------------------------------------------------------------------- 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
-- 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
