[gmpi] Re: GMPI req's draft 1 for review.

  • From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
  • To: <gmpi@xxxxxxxxxxxxx>
  • Date: Mon, 6 Dec 2004 13:21:06 +0100

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

Other related posts: