>>i'm sorry, my definition of sample-synced is "processing data for same >>time slice". i personally see no wiggle-room there. >> > >Sample-synced means sample-synced. It does not mean buffer-synced, >which is what you are talking about here. sorry, but its not. reductio ad absurdum: make the buffer 1 sample long. sample-synced means: all participants in the graph must be processing data for the same timeslice, no matter what the size of that timeslice. if you don't guarantee this, you have a system subject to mathematical errors caused by parameter changes that occur close to the mismatching timeslice boundaries. >gear may very well use sample-by-sample processing (= a 1-sample >audoio buffer /time slice), while the DAW probably uses at least >32-sample buffers. this isn't a counter-example. between time T and time T+X, both of them have processed samples that cover time Y and Y+X. >However, I think a more impportant issue is the time that it takes a >plugin it self to respond to events. If events are sent in strict >synchrony with the samples whe re they occur, then the plugin cannot >do any long calculations in response to events or it mi ght miss a >deadline. If events were sent early then the plugin could process >them with le ngthy calculations and still never miss a deadline as >long as the events were not too dense. and when or how is it going to do those computations? what if a new event arrives after the first one that invalidates the first set of results? --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