[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