On Mon, Sep 12, 2011 at 9:20 PM, Brian Matherly <[email protected]> wrote: > Hi Dan. > >>> I really like the idea of reusing the Kdenlive titler. > >>> >>> Let me make sure I understand: >>> 1) Create a new filter in MLT called "filter_kdenlivetitle" >> >> You will need to refactor the producer into a class usable by either service. >> >>> 2) Enhance or reuse the Kdenlive titler dialog to create a custom kdenlive >> title xml file >> >> The titler can already save to and load from a .kdenlivetitle file. >> >>> 3) Have Kdenlive pass the title xml file to the filter_kdenlivetitle filter >> in MLT >> >> Currently when you load from a title file, it copies the XML and puts >> into the mlt+kdenlive xml project file - the filename is lost. You >> could make DnD copy the XML, but what happens if you edit the clip? It >> would have to recopy the XML from clip to filter, but it is feasible. >> If you remove the clip from the project, the filter will still have >> its XML. You could instead track the filename, but I think it will not >> work well because editing the clip does not save back to a file and >> probably should not. >> >>> Is that what you have in mind? >> >> yes >> >>> What other uses can you think of? >> >> Supply a custom image to the wipe transition. >> Supply a custom image to the forthcoming filter mask instead of using >> rotoscope. >> >> Maybe this is a bit too complicated for such a simple need. > > Thanks for your time and consideration on this topic. I had a look at your > suggestion, and it makes a lot of sense to me. Also, I think it would be > quite easy. filter_kdenlivetitle would simply encapsulate a composite > transition and a producer_kdenlivetitle. Then, a minor tweak would be needed > to kdenlivetitle_wrapper.cpp to allow keyword substitution to be applied by > filter_kdenlivetitle. > > Do you think this is the way to go? I'd be glad to try this out if you think > it is useful. I suppose at some point we should throw this idea at the > Kdenlive team before I get serious about it. >
They are reading this but maybe busy to chime in. > Another spin on this idea: rather than making filter_kdenlivetitle, would it > make sense to add some back channel (ala data_feed) from the composite > transition to producer_kdenlivetitle so that if producer_kdenlivetitle is > being used in a transition, it can gain access to the properties of the frame > it is being composited with? The benefit is that nothing would have to change > in Kdenlive (from a UI perspective) since all titles would be producers - > that is, the user would not have to decide when to make his title an "effect" > and when to make it a "clip". I suppose this would couple the producer to the > composite_transition unnecessarily - probably a dead end. > I now agree that a filter is not elegant solution. We should keep the choice of transition separate - e.g. affine transition gives smoother animation. Today you get that choice, and as you pointed out, the user experience of clip vs. filter. Basically, the kdenlivetitle producer needs access to the properties of the A frame of the transition. We could make a transition-process event fired within mlt_transition_process() that the kdenlivetitle producer listens to. A custom event transmitter would supply the frames. The producer's listener would choose the frame that it did not create and pull the properties that it needs. Um, I need to think about what coordinates the listening. -- +-DRD-+ ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 _______________________________________________ Mlt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mlt-devel
