I know I've been a pain int the ass about a lot of these, but it's just because I want to see this work. As it is, it seems to be going the other way. No one wants to argue for the best ideas. I'm, of course, willing to go by popular majority, but I'd rather see some form of consensus, even begrudged. > Topic 7.2: In-place processing > ------------------------------- > > Q: Do we do in-place processing? I think the win of doing in-place processing is obvious, no matter HOW we do it. > a) Yes. A plugin-global flag indicates a plugins ability to do this. > This tells the host that ANY input buffer may be re-used on ANY output > (perhaps withing some higher-level grouping of stuff (think MIDI > channel?)). If a plug can not accept this rule, it must not use > in-place processing. (VST model?) This would be fine for many plugins - and fine by me, if that is hat people want. > b) Yes. A plugin statically maps inputs to outputs. The host may > re-use an input buffer for an output if they map together. If people want this, I'll cope, but I don't think it is the best. > c) Yes. A plugin is given inputs and produces it's own output buffers > based on internal knowledge or other variables. The host is not > involved, except to furnish new buffers as requested. The plugin must > re-use or release all input buffers. Variations on this can be devised > to allowed shared input/outputs. (baton passing, or similar to DX model) I think I still prefer this method, but as I said, I'll go with whatever > d) No. All output buffers are unique from input buffers. If we can't agree, this is fine, though it will be sad to step back in functionality from existing APIs. ANYONE ELSE? I know you have opinions.. ---------------------------------------------------------------------- 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