On Monday, December 06, 2004 8:38 AM [GMT+1=CET], Tim Hockin <xxxthockin@xxxxxxxxxxxxx> wrote: > Make some time - just 1/2 hour is enough. Read the first 15 sections of > the GMPI req's document and offer any feedback. This includes language > changes, spelling, grammar, etc. This is it. The draft of the final > req's document. > > Seriously, it won't take but a half a hour or less. > > http://www.gmpi-plugins.org/gmpi/requirements.php It did take me a bit longer than half an hour, but it was worth seeing it all put together now (pfew) ;-) I split up my comments in content- and purely text-related things: ===== content-related ===== 1. Goals Maybe it might be interesting to have some kind of "introduction" section explaining what GMPI stands for and why it is needed? Sure, we all know this, but a small introductory section might be enough for people who haven't lived in the dual host/plugin world before, and are nonetheless interested to get started with GMPI. I'll give it a shot (English is not my native language, so please correct/rephrase/extend where needed): 0. Introduction and background GMPI stands for "Generalized Music Plugin Interface", and is meant to become a standard interface for communication of audio streams, musical events and control signals between a "host" program and a "plugin" running in that host. A host program is the main system that provides a (more or less) rich environment of tools and infrastructure for working with the above mentioned types of data (see 1.1). A plugin is a self-contained "sub-program" that is loaded into a host program and thus extends its functionality. GMPI is needed to provide a consistent interface of letting host programs and plugins communicate with each other in a standard way. Several open and proprietary plugin interfaces exist today, and basically these interfaces all do more or less the same things, but they are still different. GMPI is meant to gather the best parts of each existing interface and bring this together in an easy-to-use generalized interface. ----- Req 4: (about ANSI C type names) Is it needed to state this explicitly? Doesn't hurt, of course, but I'd think it's contained in Req 3 (GMPI will written in ANSI C). ----- Req 11: "Plugins must not be expected to support dynamic sample rates. The sample rate must be set very early in the life of the plugin and not changed. " Can't remember if we talked about this, but what happens if the user changes the sample rate of an existing GMPI graph? That is allowed right? This would imply that it has to be done by re-instantiating each plugin with the new sample rate? (I'd be fine with that, just want to make sure I got the implication right) ----- Req 64: "Plugins must be able to change their latency, when allowed by the host" I guess it is really needed to not allow the plugin to change its latency whenever it wants, right? I can live with it, but there are cases where I would really like it to be different. I currently have a VST plugin that detects peak hights over the last x ms, and the "peak scan time" is a parameter the user can set. This parameter influences the latency of the plugin, and in VST, I can change that latency when the parameter is changed (using setInitialDelay and then calling ioChanged). I can understand though that this is must be a rather heavy burden on the host side... ----- Req 109: I remember there was some talk about a "plugin test application" performing some basic essential reference tests that your plugin should pass before it can be considered a GMPI plugin. Nothing is mentioned in the Reqs about this. Do we still think it should be there? I personally think it could be very useful to have that. I'm not sure, but I think AU has something like that too. ===== text-related ===== 4.3 Profiles: (spelling mistake) last line: "neting depth" --> "nesting depth" ----- Req 23: (missing word) "Events must never [be] delivered while a plugin is processing" --> insert "be" ----- 4.12 More on timelines: (spelling mistake, UST section) "Unadjust System Time" --> "unadjusted" "one clocks per computer" --> "clock" ----- Req 47: (missing word) "All parameters must be able [to] use natural values" --> insert "to" ----- 4.22: (spelling mistakes) 1.Linked parameters, second last line: "independantly" --> "independently" 2.Clipped parameters, 3rd sentence: "and MIN may net drop below..." --> "not" ----- Req 60: (extaeneous word) last line: "for a host to save a just a single channel's patch" --> delete first "a" ----- Req 66: (spelling mistake) "for storing plugin state independantly" --> "independently" ----- Req 67: (spelling mistake) "storing a group of plugin preset files int a bank of presets" --> "into" ----- Req 91: (rephrase) "Each plugin (dynamically loadable) file must be capable of containing more than one plugin." --> "... may contain more than one plugin" ----- Req 92: (missing word) last line: "A bundle directory must never [contain?] other bundles" --> insert verb Hope this helps, Koen ---------------------------------------------------------------------- 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