>>> >This is sounding more and more flaky to me. I'm starting to think that >if a plugin changes it's interface, it's got to be treated like a new plugin. what he said ... <<< Eek no! If a plugin sprouts new parameters or pins, or takes them away, these things aren't recordable. No more so than recording patching the plugin in the first place. I personally don't like the approach that says new parameters need to be exposed via new modules. It puts an unecessary burden on a plugin that wants dynamic parameters (or pins), but isn't necessary modular. Someone asked what happens if a parameter goes away. Simple answer: it becomes an "orphan". We have these on SONAR, it happens when you patch a plugin, automate it, and then delete the plugin instance. The envelopes remain but they don't control anything. The user can reassign them later to another plugin if they want to. To me the simplest design for this is to allow params to come and go, with a necessary step that plugin first calls back into the host to ask for permission. Maybe part of these design is for the host to publish if it support dynamic parameter or IO changes, so that the plugin can fall back into a more static mode if not. ---------------------------------------------------------------------- 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: http://www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe