I agree that we should have only one point to query a plugin for its
loadability. To further clarify cacheability by the host, we should add:
- The plugin must state whether or not its configuration data is
required to be loaded from disk on host startup (i.e. is the plugin's
configuration "cacheable.")
An example of why this is necessary would be a plugin which relies in
some way on hardware. With certain hardware present, it might have more
configurations available. And the hardware state may change between host
runtimes. Almost all plugins would responds that they are cacheable.
Mike
Paul Davis wrote:
I would be happy to drop external metadata, and use only loading a library and calling a probe function.
when torben hohn and i implemented libfst (which provides in-process support for win32/x86 VST plugins on linux using Wine), we found that the cost of loading a lot of win32 dlls in that environment was astronomically high. as a result, we adopted a system where the FST API includes a call to return basic info about a plugin. if a cached version of the info exists, and the cache is newer than the dll, we use the cache. if the cache does not exist, or is older, the call builds the cache (its a normal text file), and then returns the info.
this sped up loading VST plugins by a factor of about 100 :)
despite this, i think this should probably be left to hosts or wrapper libraries, because of the issues with file ownership and cache updating. the only acceptable metadata for me would be some way in which text information was buried in a section of the object file, and accessible. but if the plugin file format is a standard obejct format (ELF, COFF, a.out, etc. etc), it would be really hard to do this in a platform independent way.
--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
-- Mike Berry Adobe Systems
---------------------------------------------------------------------- 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
