From: Brian M. <pez...@ya...> - 2013-02-18 04:05:38
|
Hi, 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. I've been researching this part of the Kdenlive code and I found that there are two ways that MLT producers are exposed: "clips" and "generators". My frist inclination was to make generators for all producers. But I don't care for the fact that you end up with another MLT file to manage with the project and that the generated clips can not be extended on the timeline by clicking and draging. It seems to me that it would be better if the clips were implemented like the color clip. But that would require more code in the clip manager - and I don't know how scalable that would be. It would sure be nice if the clip manager supported a generic MLT wrapper architecture like the effects stack. That way, when new producers are added in MLT, Kdenlive could adopt them just by adding a new XML file. I'm willing to put in some time to make the clip manager more generic. But I'd like to hear your thoughts on that first. If you aren't excited about having changsd made in there, then i would be content to just implement more generator plugins. Thanks for your thoughts, ~Brian |
From: Till T. <ro...@tt...> - 2013-02-18 17:58:40
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/18/2013 05:05 AM, Brian Matherly wrote: > Hi, > > 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. > > I've been researching this part of the Kdenlive code and I found > that there are two ways that MLT producers are exposed: "clips" and > "generators". My frist inclination was to make generators for all > producers. But I don't care for the fact that you end up with > another MLT file to manage with the project and that the generated > clips can not be extended on the timeline by clicking and draging. > It seems to me that it would be better if the clips were > implemented like the color clip. But that would require more code > in the clip manager - and I don't know how scalable that would be. > > It would sure be nice if the clip manager supported a generic MLT > wrapper architecture like the effects stack. That way, when new > producers are added in MLT, Kdenlive could adopt them just by > adding a new XML file. > > I'm willing to put in some time to make the clip manager more > generic. But I'd like to hear your thoughts on that first. If you > aren't excited about having changsd made in there, then i would be > content to just implement more generator plugins. Hey Brian, 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? regards, Till > > Thanks for your thoughts, > > ~Brian -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEibCEACgkQzwEyz7QP6nQ/xQCfSmT6Se+cRr7F0ICm9GJIXaHd XrYAoKFbPuF94cNCOZChqrckIruWJuzI =KcrL -----END PGP SIGNATURE----- |
From: Brian M. <pez...@ya...> - 2013-02-19 14:20:10
|
>> 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. Thanks, ~Brian |
From: jb <jb...@kd...> - 2013-02-23 16:14:33
|
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 |
From: Brian M. <pez...@ya...> - 2013-02-23 19:54:39
|
JB, >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. Great. It sounds like the refactor will be in master in about 3 weeks. I'll bring the topic up then and we can decide how to proceed at that time. ~Brian |
From: Till T. <ro...@tt...> - 2013-02-26 18:51:33
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/23/2013 05:14 PM, jb wrote: > 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. Shouldn't we move the refactoring branch to next first and only move it master when at least all core functions are ported? master is used by quiet a huge amount of people after all... > > 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. Sounds like a good idea. Additionally we could set up a list with tasks and ideas. Would mantis be appropriate for this? Btw. I started working on (and hopefully will have time to finish this week) adding clips to the timeline, this affects Bin and Timeline, UI + Model. greetings, Till > > regards jb > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEtBEgACgkQzwEyz7QP6nSFMgCgwAGfPMal6EcHJn9QrKkF2DQg J+wAn0OxkYAJjwegtZlV2vw8HFie8eUc =o56C -----END PGP SIGNATURE----- |