Could plugin makers and hosts use this meta data to instantiate a sort of read-only version of the plug? Kind of like Acrobat and Acrobat reader. I am not sure how in practice they would make it "read-only" (since that model doesn't really quite fit into this). Perhaps the key would be to: Not allow a plug to be additionally instantiated in a new track or effect bin, it could only remain within that track. Allow the plug to deinstall itself after a session, i.e. when the plug is closed it initiates an uninstall Allow a plug with the aid of the host to obscure where to place the plugin for temporary use (occluding it from users to minimize a possible form of pirating, possibly also using encryption) Lock some of the parameters to limit the full functionality of the plug, for instance, not allow a change of preset or in the case of a softsynth only download wave data which is applicable to the preset chosen (of course, wave data like this could also be saved as meta data). This sounds like a lot of programming on the plugin side of the house but I could see user's finding this very advantageous for collaborative work. Regards, Ryan Fogarty ----- Original Message ----- From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx> To: <gmpi@xxxxxxxxxxxxx> Sent: Monday, August 30, 2004 11:20 AM Subject: [gmpi] Re: Instruments done, moving on to "Plugin Files" > I totally agree. This is a huge win. The plugins meta-data can point > to the vendor's web site, so if User X doesn't have a plugin used by a > project created by User Y, they can go to the vendors web site. Yet > another way how standards can grow markets. > > -----Original Message----- > From: gmpi-bounce@xxxxxxxxxxxxx [mailto:gmpi-bounce@xxxxxxxxxxxxx] On > Behalf Of lists@xxxxxxxxxx > Sent: Friday, August 27, 2004 9:38 AM > To: gmpi@xxxxxxxxxxxxx > Subject: [gmpi] Re: Instruments done, moving on to "Plugin Files" > > Great thought, Steve (though I'm interested to hear if anyone > (commercial devs?) disagrees). I'd like to see this rationale made > explicit in the req's, perhaps by fleshing out #88. - Jim > > > At 10:08 AM +0100 8/27/04, Steve Harris wrote: > >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. > > ---------------------------------------------------------------------- > 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 > > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- 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