[Kdenlive-devel] Release and future...

Till Theato root at ttill.de
Mon Sep 5 14:48:54 UTC 2011

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
>>> 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?


> 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
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the Kdenlive mailing list