Steve Harris <steve@email-addr-hidden> 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>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
This archive was generated by hypermail 2.1.8 : Thu Nov 15 2007 - 00:15:02 EET