[Kdenlive-devel] Effects idea

[Dan Dennedy]

On Friday 02 March 2007 16:12, jb wrote:
> On Friday 02 March 2007 09.52:51 Zsolt Sandor wrote:
> > - Modify the mlt framework that it can use effects and transitions in
> > .so format.
>
> I think it is already the case, you can have a look in:
> /usr/local/share/mlt/modules/

BTW, on my todo list is to move these to $prefix/lib/mlt

> But currently, effects (filters) are grouped with producers in some big
> categories (core, mltplus,...). I do not have enough knowledge to really
> comment on this, but having one library for each effect would probably
> result in a worse real time performance.

The grouping is rather arbitrary based upon a subdirectory of mlt/src/modules. 
Things tend to be grouped based upon external dependency, licensing, and 
contributor/copyright.

> > - Create an xml schema that can describe an effect (and one for a
> > transition). It should contain a link to the so file, the parameters,
> > the function names bound to the parameters, and so on.
>
> Yes, I have been thinking about it for a some time, would be much better
> than current situation. The best thing would be to have a place in MLT data
> folders where xml files for the installed effects / transitions would be
> installed, then Kdenlive would just have to parse this folder to
> automatically create all effects.

I am glad we are all thinking the same thing because Charlie and I did some 
brainstorming similar to this in July, 2004. I even generated a sample and 
discussed some minor additions to API and miracle/DVCP for an applcation to 
query for the XML.

> Still, one thing I am not sure is how we could manage translation of the
> effect names and parameters, because all names will be in MLT and not in
> Kdenlive anymore...

Yes, they would have to be managed separately, but we can now closely 
coordinate kdenlive and MLT since you have CVS access and kdelinve is now 
MLT's primary user. There can be high level XML elements with a language 
attribute for filtering.

From this metadata, you have the introspection to build a generic GUI, but 
that's not very nice. In 2004, when we discussed this, it was in the context 
of Kino and GTK+ where we pondered the usage of Glade XML, but that also 
raised the issue of how to bind the UI controls to an object's properties. 
Would kjsembed work for kdenlive?