[Kdenlive-devel] Support for more clip types

[jb]

On Tuesday 19 February 2013 06.20:02 Brian Matherly wrote:
> >>  I've been inspired to add support in Kdenlive for more of the
> >>  
> >>  producers in MLT. Right now, you can make color clips and you can
> >>  use the generator plugin to create a noise and count down clip. But
> >>  MLT exposes some other producers: like the Frei0r test patterns.
> >>  And I'd like to add some audio test tone synthesizers.
> >> 
> >> <SNIP>
> > 
> > in case you do not need this feature immediately you might want to
> > have a look at the refactoring branch. There we have
> > AbstractProjectClip (src/core/project/abstractprojectclip.h),
> > AbstractClipPlugin and AbstractTimelineClip which can be subclassed
> > for different types of clips/producers (See src/plugins/cliptypes).
> > Currently the implementations of image (qimage/pixbuf) and video
> > (avformat, should be renamed to av) are started. These two cannot be
> > made more generic because of things like exif data or the requirement
> > to have different base producers for different tracks (audio issues
> > with avformat).
> > 
> > But especially all the "generators" which do not use an input file
> > could probably be handled by one single clip type plugin. For example
> > by making using XML files similar to the ones used for effect
> > descriptions. Just as you proposed.
> > What do you think?
> 
> Till,
> 
> Thanks for redirecting me to the refactor branch. Things have certainly
> changed there. And I think it will be easier to add more generators in the
> new code. Based on what I saw, I agree with you. I think we could make a
> new clip type called "producerclip" or something similar. It could provide
> configuration for all the simple MLT producers like noise, color and
> colorbars.The producer properties could be automatically exposed to the
> user by querying the MLT metadata. If the producer properties can't be
> extracted from the MLT metadata for some reason, then we could provide an
> XML override to allow the parameters to be described manually.
> 
> I'm in no hurry. So I can wait for the refactor branch to be done. Do you
> have any idea when the refactor branch will be merged into master?
> Alternately, I could start hacking in the refactor branch. But I don't want
> to get in anybody's way.


Hi,

Sorry for taking so much time to answer...
I completely agree with the producer proposal. I am currently busy fixing bugs 
for the 0.9 branch and hope to make a release in about 10 days.

When I make the release, I will make an announcement and a week later, we 
could move the refactoring branch to master. It is important that we give some 
delay because several packagers / build scripts are using current git master 
to provide a "bleeding edge" version of Kdenlive, and they will need to switch 
to the 0.9 branch until refactoring is usable.

I will be really happy to start working on the refactoring branch. However I 
don't know how we can coordinate the work between us since some core parts are 
changed. I think maybe we can use the list when we plan to work on a part of 
Kdenlive to explain basically what we plan to do so that the others can speak.

regards
jb