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