[gmpi] Re: Instruments done, moving on to "Plugin Files"

On Thu, Aug 26, 2004 at 10:38:30 +1200, Jeff McClintock wrote:
> Hi,
> 
> I'm a little confused by Req 88 ... "Plugin metadata must be available
> without loading/linking a plugin dll"
> 
> This implies that plugin metadata might be stored externally to the dll.  I
> assume this is a performance hack, the assumption being that the host can
> enumerate plugins faster if it doesn't have to load/link each one in order
> to probe it's capabilities.
>    How can an external file describe a plugin, when the plugin's IO and
> parameter list is potentially 'dynamic'? ( Req 53:   Plugins must be able to
> perform seemingly spontaneous parameter changes. )

Right, so the metadata should not include i/o arrangement, or not always.
In any case, if the i/o arrangement is dynamic then an uninstantiated and
unconfigured plugin wont know what its i/o arrangement will be either.
Instatiating each plugin and changing controls to find out how many ports
it can/will have really is too much work to expect a host to do for each
plugin. I suspect that plugin with dynamic creation and deltion of ports
will be the exception, rather than the rule, so maybe its acceptable if
thier a bit of an unknown? If theres some reason why hosts must know the
number of ports in dynamic plugins then the metadata could indicate a
range of possible values.

Storing the metadata in a seperate part of the plugin means that we could
require it to be freely licenced, which would make the metadata of every
plugin free for use, even though the plugin itsself isnt eg. to include in
session files to make sessions more easily portable between machines. that
way the receiver can know exactly what plugins thier missing and make
substitutions as appropriate.

This is not so important where you only have proprietary session formats,
but it could be an important component of open, interoperable session
files, such as the one promoted by the BBC (I forget its name).

> Secondly, it's dangerous to have two ways of querying a plugin ( 1-
> directly, 2 - via an external file).. which is authoritative?, what if the
> two do not agree?

Agreed, its important to know where to get what information from and
duplication is very bad.
 
> Lastly, there are better ways to achieve the performance gain.  Cubase, for
> example, queries all plugins just once, and stores the results in a single
> database.  The host never needs probe a plugin again (except new ones).

Yes, but every host needs some similar arrangement, so its a bit wasteful.
If every host can all just parse it out of the same file it should save some
time, but I suspect the performance issue is negligable.

- 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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: