> (8: Are data blocks passed along down the stream and reused where > possible, or effectively owned by a single i/o connection pair? Is it > legal to expect a plug to use the same buffer for input and output and > pass it on?) Buffers should be re-usable (allocated by the host) except in a few cases (see below). Plugins should be able to identify whether they can use the same input and output buffers, or whether they need different buffers. Default to assuming that all buffers are distinct, and let plugins specify "I'm in-place safe!" or vice versa. I don't know that the default matters. Saying "I'm in-place safe!" is a good PR point for plug makers, but being forced to say "I'm in-place broken" is also pretty strong. It was mentioned that plugins may want to allocate their own buffers (device memory or whatnot). Should this be allowed, or should we make this the responsibility of the proxy to copy the data in/out of device memory? Also, wrt buffers - something we talked about in XAP: optimizing plugs during silence. Buffers originate at instruments. If the instrument doesn't produce any data, the buffer is effectively silent. Some plugins might be able to skip some work if their input is silence. So what we talked about was this (totally optional for host and plugins): 1) Flag all buffers as SILENT. 2) Whenever a plug writes to a buffer, remove the SILENT flag. 3) Any downstream plug can see the SILENT flag and do whatever it wants with it. Hosts can just never set the SILENT flag, and it will never bother anyone. But if they want, they can set the SILENT flag and avoid some work (no need to zero the buffer if we know it is silent, maybe?). Plugins that respect the SILENT flag might avoid some work, and plugins that don't would do their thing. The only thing required is that plugins need to identify whether they can accept SILENT buffers. 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