Amen - having been through the consensus process with LADSPA before, I reckon it'll be a real challenge to get folk to read everything if we get too tangential - I must admit I'm already skimming heavily! It might be worth setting up a Wiki (or whatever those things are called) to develop ideas in an organised fashion. I must admit I'm not going to have time to read all these emails so I'll probably skim and catch up from time to time, so it would be good to have a place where the current state-of-the-art could be explored. On the requirement side, as a start point with LADSPA I made sure I'd been through lots of APIs that were out there already. There may be some clues there... LADSPA's aim was to be a greatest common denominator (aiming at general host compatibility) rather than a generalisation or "better way". Even so, we probably don't want to be too general or requirements will end up as the specification for an operating system. As a baseline requirement, can I propose that GMPI does everything LADSPA does (although not necessarily in that way)? As folk on the LAD list know, to keep things lean I've been a complete stick-in-the-mud about any feature that wouldn't be useful to most hosts, so I don't think there is anything in there that we would *not* want. Only way to handle the flood of ideas... Note that LADSPA doesn't attempt to approach GUIs - there wasn't enough consensus on how to do this IMHO. Unfortunately for sanity of discussion, this probably falls in GPMI's scope ;-) At the very least we ought to try to keep these GUI+plugin very separate (after all, we may be selling dedicated rackmount hardware implementing GPMI before we know it...). Good luck to everyone - this is an ambitious project. Please don't flood my mailbox too badly! I'm going to go quiet for a while to see where things start to settle... --Richard -----Original Message----- From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx]On Behalf Of Paul Davis Sent: 11 February 2003 15:33 To: gmpi@xxxxxxxxxxxxx Subject: [gmpi] a little order? can i suggest that we perhaps follow a slightly more orderly approach, at least to start? folks familiar with LAD will know how conversations like this can rapidly swing into a multiplicity of different orthogonal orbits. since the purpose of the discussion is to frame the requirements for a "unified" plugin API, i'd humbly suggest that we start by listing things that we specifically do or do not like about existing plugin APIs. no solutions, no new designs - just list the things that are either problematic and need replacing/providing, or things that are so great you wouldn't want them to go away. remember non-audio/MIDI plugin APIs as well, if that seems relevant. --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 ---------------------------------------------------------------------- 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