[gmpi] Re: Reqs draft
- From: RonKuper@xxxxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 7 Nov 2003 16:29:40 -0500
And by the way, thank you thank you thank you to Tim and others for taking
on the job of writing the first draft. I think we'll be able to move along
into the specification stage much quicker with a requirements doc that we
can pick at, vs. trying to write one from scratch.
Plugin Discovery
---------------
* How are plugins discovered on the system?
- registration required in a central DB?
- a directory that must be scanned?
---> Some central DB, which could be nothing more than an "index" file at
the root of a directory. Simply copying into a directory presents
versioning problems, and having to scan at startup if a huge inconvenience
to users.
* What info/services must the host provide at instantiation vs. runtime?
---> Don't understand this question. I think all host services must be
available always?
* What must the plugin provide the host at instantiation?
---> I want to say "meta data" about parameters, their names, ranges, etc.
But parameters can come and go dynamically, so maybe this information isn't
available at instantiation time?
* How do wrapper plugins (e.g. VST in GMPI) fit into this?
---> Implementation detail in the wrapper. Today there are 2 different
VST->DX wrappers and they each work perfectly, each in their own way.
DSP state
-------
* When must/may the host reset a plugin?
---> Up to the host. Some hosts might be "lazy" and want to reset every
time the user presses [stop] on their transport.
non-FPU systems
------------
* Do we REALLY want to support non-FPU systems?
- means we need to have float and int sample types
- means 'real' parameters can not be float
- means that anywhere we want to use a float or double needs to change
---> Yes, we do. I think we should do this by a type definition, that's
defined globally for the plugin "profile." In 99% of the plugins, we'll
have "typedef SAMPLE_TYPE float". For non float systems, it can be "typedef
SAMPLE_TYPE int32" (or whatever). Then its up to the plugin code to manage
the math. I would love to be able to support ProTools TDM, which means we
need this.
* If we do support it -- profiles -- what falls into a profile?
- samples (int16 or int24 or 'real')
- definition of 'real' and operations for reals
- ???
---> Data type for sample, perhaps channel format (split mono vs.
interleaved) too.
----------------------------------------------------------------------
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:
