[Kdenlive-devel] Release and future...
Till Theato
root at ttill.de
Mon Sep 5 14:48:54 UTC 2011
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 09/04/2011 12:26 AM, Till Theato wrote:
> On 09/03/2011 01:06 AM, jb wrote:
>> On Saturday 03 September 2011 00:44:46 Till Theato wrote:
>
>>>> 1) Change the effect XML depending on the filter version
>>>>
>>>> I did some test and managed to have a working implementation
>>>> that will bring different parameters depending on the filter
>>>> version, see my last commit:
>>>> http://kdenlive.svn.sourceforge.net/viewvc/kdenlive?view=revision&revisi
>>>>
>>>>
>
>>>>
on=5855
>>> Is
>>>
>>> it correct that only one file was committed?
>
>> Yes. It is possible to put several effects description in just
>> one file if we put the effects in a <group> tag.
>
>>>
>>>> 2) upgrade project files using older version of the filter
>>>>
>>>> Since MLT now stores the frei0r filter version in the xml
>>>> data, it should be pretty straightforward. Till, are you
>>>> taking care of it? I will have some time between the 5th an
>>>> the 7th of September in case some work is required on that
>>>> side.
>>>
>>> Sorry for the delay, I am fighting with QtScript for a week
>>> now (with little spare time). The result unfortunately is a lot
>>> of redundancy across the XML files and overall ugliness. As you
>>> can see in the attached file: Way to much code for only a
>>> single file... The adopt function could be replaced by what
>>> you introduced in your latest commit or by what Dan proposed:
>>> Do the same thing you implemented but on parameter level (->
>>> less duplication).
>
>> Currently, it seems easier to me to check it at the effect
>> level. Having it at the parameter level could bring some
>> complicated stuff (imagine that we have 3 versions of a filter,
>> each having different minimums, maximums, parameters appearing or
>> removed... That would in the end result in a very complicated
>> xml.
>
>> In my version, we simple put one xml copy for each version of
>> the filter, and Kdenlive will only load the correct version.
>
> The attached patch is what i came up with. As I already said I
> will drop the adopt function (and therefore the changes in
> initeffects.cpp) again. With your system where should the routines
> part be placed?
@jb?
> Since it is needed in trackview it has to be inside <effect>.
> However there will be at least two <effect> elements whenever a
> routine is needed. Another problem is see with your approach is the
> amount of duplication, since some XMl files are not that small
> (e.g. SOP/Sat).
>
> Any ideas to avoid duplication in the update function (across
> multiple effects)?
>
>
>
>
>>> Regarding the update thing I don't know.... Levels is a rather
>>> easy example but on other effects we can't just multiply the
>>> whole thing by a factor since we also have to consider
>>> keyframes. Rather easy however with the update function
>>> concept. Anyone any ideas on how to do it with less code?
>
>>> The adopt function is fully integrated in Kdenlive and works,
>>> but is probably to be removed again. The result of the update
>>> function is not yet replacing the original effect in the
>>> project. I will try to finish it this weekend. Well that is
>>> unless someone comes up with a better idea.
>>>
>>> For the update thing to work a MLT release would be required,
>>> too. @Dan?
>
>> Oh, you mean because the frei0r version is new in MLT... right I
>> didn't think about it...
>
>>>> Once both steps have been taken for the filters that will be
>>>> modified in frei0r, I will prepare the release.
>>>
>>> What about that 10 tracks bug?
>
>> That's an MLT issue, I have not investigated more.
>
>> regards jb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk5k4VAACgkQzwEyz7QP6nQh8wCcC599dKhZXrkDcVjBcLih6FEw
uYAAn2IVaJYPNoZGeSKgkqNmDjJlvaw+
=d4cZ
-----END PGP SIGNATURE-----
More information about the Kdenlive
mailing list