[gmpi] Re: Reqs draft
- From: Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 8 Nov 2003 14:11:30 +0000
On Fri, Nov 07, 2003 at 03:09:37 -0800, Tim Hockin wrote:
> > ---> 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.
I dont see how an index file is any different to a directory. You still
have the issue that you have to remove files refering to plugins that no
longer exist and add entries for plugins that are added, but a directory
removes synchronisation problems.
> I think the requirements should include something like:
> * there is no system-global registration needed for plugins
> * plugin installation can be as simple as dropping a file into a dir
> * hosts should examine the $GMPI_PLUGINS_PATH environment variable and
> recursively scan each entry found
That is more or less how LADSPA+RDF works. I dont really know wether its
succesful or not.
> As I see it, sample-rate is set at plugin-instance creation and never again.
> To change sample-rate, destroy and re-create the plugin. I don't know if
> anything else needs this level of treatment. Sample-rate is a big deal. If
> we make plugins support dynamic sample rates, the code gets harder.
Agreed, personally I dont want ot have to deal with that. It can be hidden
by the host requesting a state dump, reinstntiating the plugin and making
it restore from the last state.
> My first thought was that each dll (or .so) file could indicate 1 or more
> plugins that existed in that file. The full list of plugins that the host
> could access was the set of all plugins in all dll files.
...
> When probed, vst_wrapper examines the VSTPlugins path and returns
> all the plugins that it can find.
Yes, this is what the LADSPA/VST and LADSPA/jMax wrapper plugins do. It
works well enough.
> > ---> 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.
>
> So do we just provide the typedef and no operations? Does that make float
> parameters become int32, too? What about double parameters?
We would need to define low- and high-precision reals if we need float and
double parameters.
- Steve
----------------------------------------------------------------------
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:
