I would like to propose some other items to add to the agenda: Programming pattern (C only, C++, multiple inheritance, templates, template inheritance, template metaprogramming, etc.). Multiple inheritance could offer a way to provide base classes with functionality "decomposed" into basic and advanced layers, functional areas, etc. Requirement (or option?) for "scriptability" via SWIG .i file, adapter classes, etc. on the grounds that commercial music software offers scripting environments and this is likely to increase in importance (CAL, Finale, Sibelius). I think the degree of complexity of the protocol/difficulty of programming it should be high on the agenda. Another item would be whether or not to provide an operating system abstraction layer for plugin code to call from a library class (such as "gimpi::System") for files, sockets, threads, synchronization, heaps (GUI example: VSTGui). Another item would be whether or not to coordinate and/or integrate with initiatives of MPEG, some of which are very far reaching, e.g. SAOL/SASL, audio scene graphs, etc. Another item would be whether or not plugin libraries are required to use "class factories" to produce implementations of abstract plugin interfaces (highly recommended!) which would enable remoting of implementations via RPC, render farming, parallel processing, GRID access, etc. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . ---------------------------------------------------------------------- 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