> I think it is clear that people are losing interest, and I believe this is > because there is no immediate reward for our thoughts. Possibly, people > should propose models of a complete plugin API, several alternative models > that is, and solicit contributions and refinements. Then we could vote, or > something. These models would be in the form of stub host/stub plugin and > enable all negotatios, graph construction, etc. Hi Michael et all, I like Michael's proposal. We spend a lot of effort arguing about implementation details, and a lot of time arguing about which of two approaches is simpler/more efficient/etc. If we had an *absolute* minimum implementation. It would provide a test bed for various ideas. I don't know how many times I've dreamt up a simple, elegant design, only to have it crash and burn under the harsh reality of actually coding it. We could get some real performance figures for "baton passing vs pre-allocated buffers" for instance. I suggest it's also a more modern, iterative approach to design. ("Extreme Programming" is the label). Our current approach is more 'top-down'?, is that the term?. (the word "Bloatware" also springs to mind, but perhaps i'm biased). The downside is the potential chaos of managing the process. What do you all think? Best Regards, Jeff M ---------------------------------------------------------------------- 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