> 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