Events with a sample-accurate timestamp get my vote. This way you can approach audio-rate in cases where you must. In cases where it is an absolute necessity that the plugin apply a perfect-slope DSP change ( algorithmic signal generation or something ? ), the host could allow the plugin to "look ahead" into the next value(s) to generate a higher order curve fit. This was discussed before but I don't know if it made it into the spec. I'd leave it out personally. Of course in real-time, a "ramp" or "slope" value is impractical to implement anyway. If the user is twiddling a knob, there is no way to anticipate what or when the next value will be ... if you try to generate a slope based on the last value, you may overshoot when the user stops turning a knob. Of course during automation playback, you have the ability to generate ramps but then you have the problem where the playback does not exactly match what the performer heard when recording (bad!!). In my experience, every DSP element works the same way internally: give me a new value and I will ramp towards it at some arbitrary rate. I think some DSP filtering processes would become unstable if they were to track an arbitrarily changing value at audio rate. The DSP change must necessarily lag behind the operator. This means that every DAW operator in existence is used to hearing the effect of a plugin some time after the change shown on our monitor. Our brains accomodate this delay and we can make it sound "right" without any software intervention. -Ben Loftis ---------------------------------------------------------------------- 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