Steve Harris <[EMAIL PROTECTED]> writes: > On 14 Nov 2007, at 15:26, David Olofson wrote: > >> On Wednesday 14 November 2007, Krzysztof Foltman wrote: >>> David Olofson wrote: >>>> I would think that users might want some way of "upgrading" their >>>> project files to use new plugin versions without just manually >>>> ripping out and replacing plugins, but even without some API help, >>>> I'd rather not see hosts trying to do this automatically... >>> Well, a common solution is to store plugin version identifier (it >>> could even be a sequence number assigned by plugin author) in the >>> song. Then, the plugin is able to convert at least the current >>> parameter values (but not, say, automation tracks) on song load. >>> >>> It doesn't solve *all* the compatibility problems, but can solve the >>> most immediate one, I think. >> >> Provided plugins are identified by URIs, and same URI implies 100% >> compatibility, how do you actually find the new version of the >> plugin? >> >> Then again, in that case, we're really talking about a brand new >> plugin, but it seems to me that there is some useful grayzone here; >> plugins that are mostly compatible with their predecessors. New major >> versions, if you like. >> >> Provide a version history in the form of an array of URIs, so hosts >> can find and deal with this if desired? > > Yeah, that makes a lot of sense.
version history in form of an array of URIs makes sense to me too -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>
pgpWcfWf4wZds.pgp
Description: PGP signature
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
