Well, if plug state is a blob, and the host handles save/restore for
plugs, then the plug could include any desired banks (including
factory presets) in the blob.
But sure, of course a plug writer would want to be able to have
user-extendable patch/bank libraries for each plug product. (E.g.,
all instances of plug P include a 'presets' pull-down menu, and users
can save plug state at any time from any instance of P into the
preset pool, such that it becomes available to all future P
instances). I guess the choices are either a) you let plugs access
the file system in a free-form manner themselves (though preferably
mediated through the GMPI API so that code doesn't have to be
re-written per platform), or else b) you create specific patch/bank
management in GMPI.
My hunch is a) is better, maybe with some guidelines about where in
the file system a plug is allowed/encouraged/etc. to collect its
patch/bank files. I'm worried (perhaps overcautiously) that if we
try to provide a framework for this, folks will need things we
haven't thought of and just do a) anyway.
-- Chris G.
Are plugins not allowed to do patch manatgement themselves? I know a lot of VSTs that have their own way of doing bank/patch files that would not be happy if we told them they can't do that anymore.
Since this touches on self-automation and plugin state and properties and structures, I saved it for last.
How do you envision GMPI handling patch/program load/change?
Tim
---------------------------------------------------------------------- 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
