<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div><br></div><div>On Sat, May 11, 2019, at 10:28 AM, Tobiasz KaroĊ wrote:<br></div><blockquote type="cite" id="qt"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="auto"><div dir="auto"><span style="background-color: rgb(255, 255, 255); color: rgb(31, 31, 31);">If you want to just "cut the tape" and don't need any effects or compositing - Kdenlvie may be acceptable. But not if you want to do anything more complex.</span><br></div></div></div></div></div></div></blockquote><div><br></div><div>I don't think this is true, and I strongly dislike the implication that people who use Kdenlive aren't "serious" editors. I've been using Kdenlive since at least 2012, and over the years, I've done all kinds of compositing, rotoscoping, color correction, chroma-keying, and other things with it beyond simply "cutting the tape."<br></div><div><br></div><div>I do agree that the limitations you talked about are very real issues-- I have felt like I'm "pushing the limits" of Kdenlive with some of my projects (although I'm always proud to do so.) I didn't even realize how much of an issue the lack of GPU utilization was until I tried Resolve for a month. (I still ended up coming back to Kdenlive because it's libre software and because Resolve doesn't work with the open-source AMDGPU drivers and ROCm OpenCL, though.)<br></div><div><br></div><div>As far as "starting over" goes, my impression is that that's the point of refactoring sections of the program: to get rid of the old built-up crud that's holding things back. I would be interested to know how closely the Kdenlive devs work/are willing to work with MLT to improve it alongside the frontend.<br></div><div><br></div><div>Just my two cents, since it seems like it's sharing day.<br></div><div><br></div><div>- Jacob Kauffmann</div></body></html>