<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08.05.19 19:42, Harald Albrecht
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>This is totally frustrating as the new timeline doesn't allow
the same multitrack compositing as the old does. Things that
worked for several years in Kdenlive cannot be done anymore in
19.04. Nada. Don't work. And this is not just an "import
problem", it also happens when you create the same project anew
in 19.04. What reason is there to completely change the track
compositing mechanics during refactoring? Please give me some
clue why things get completely broken for what is called the new
"stable 19.04" Kdenlive.<br>
</p>
</blockquote>
<p>Hello Harald, all<br>
</p>
<p>As several people already mentioned, the 19.04 release was a huge
work and many things were far from perfect. However the release
helped us get more feedback and we are fixing the problems as fast
as possible </p>
<p>It is definitely on our roadmap to provide a reliable editing
workflow. All compositing issues you reported in this mail are now
fixed in git and available in the latest AppImage uploaded today:
<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://files.kde.org/kdenlive/release/kdenlive-19.04.2e-x86_64.appimage.mirrorlist">https://files.kde.org/kdenlive/release/kdenlive-19.04.2e-x86_64.appimage.mirrorlist</a></p>
<p><br>
</p>
<p>Several different bugs triggered the problems you experienced.
Sorry for that but as you know we are a small (but growing :))
team. Several UI performance improvements were also recently
committed, so it should result in a smoother experience.<br>
</p>
<p>Hope the recent fixes will make it possible for you to continue
and enjoy working with Kdenlive, don't hesitate to report issues.</p>
<p><br>
</p>
<p>Regards</p>
<p>Jean-Baptiste<br>
</p>
<p><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net">
<p>Alas, here's what is happing; project is attached. And no, this
ain't a superficial and artificial project to annoy devs. This
is the simplified and neutered version of what I was doing in
many of my daytime company-internal video projects. And I have
to admit that there's now almost no day where I don't seriously
consider throwing the towel and shelling out money for a
commercial video editor for Linux. It's not that I haven't
raised several important issues during the refactor branch with
existing project. All I got was "oh, importing existing projects
isn't of any importance to us". Well, you could have used that
to quickly gather tons of real-world tests instead of a small
set of artifical unit tests. And to add more insult, I get told
during café that my Kubuntu disco OS setup "must be special"
when things break, so it's obviously my fault.<br>
</p>
<p>I already experienced a rough transit during those days back of
0.9x to 1.0/15.xx -- and I invested lot of patience as did JBM
with losts of real-world examples that broke during transition,
the same bugs getting squashed and returning multiple times
during transit. So, I understand how difficult such transits
are. And I perfectly understand JBM and the other devs to be
done with such difficult and exhausting transitions as a major
refactoring. Been there, lived through that. But there was a
different attitude then.<br>
</p>
<p>What, to my personal experience, is different this time is that
I experience more or less an attitude getting more and more
bordering on what feels to me like "get off my lawn". Not least
reaching peak in that ugly "importing existing project isn't of
any importance yet" some weeks ago when I raised my issues.
Honestly, I don't feel any need to file Kdenlive gitlab issues
after that treatment even up to the café. I know from my daytime
job the importance to take user feedback and bug reports very
seriously, more so when refactoring a product that worked
sufficiently good for the existing user base (notwithstanding
that it needs refactoring nevertheless).<br>
</p>
<p>Just for the record, I'm also doing development during my
daytime, to verify my architectural suggestions, so prototype
novel ideas, and to keep knowing what's like in a rapidly
changing world of software. I'm not talking ex cathedra, I leave
that to others.<br>
</p>
<p>***<br>
</p>
<p>This is the minified example of a typical track compositing I
use very often. Track compositing is set to "high quality". So,
some video "background" on V1 (to use new terminology). I then
need to focus viewers on a certain area in this background video
by darkening the unimportant parts in the video: using a
full-frame gray matte on V2, from which I cut out the region of
visual focus using a "cutout title clip" on V3. V3->V2 is
composite&transform with "destination out".<br>
</p>
<p><img src="cid:part1.8743E539.97B3019B@kdenlive.org" alt=""
class=""></p>
<p>The V2->V1 composite&transform is just for a fade in
with an alpha ramp from 0% to 100%.<br>
</p>
<p>Now, on top of this is some text with a title bar, on V5 and V4
respectively. V5 and V4 each get faded in with 0%->100%, and
composited onto V1, the bottommost background/video track. As
you can see here, this works as expected: the title and its bar
slowly fade in, and also the matte with its cutout also
correctly fades in. Also, at the end of the transitions for V5
and V4, the text and its title bar correctly reach 100%. Keep
this in mind for comparison with the new refactored behavior.<br>
</p>
<p>alpha 50% <img src="cid:part2.FB684A0B.013FF8FE@kdenlive.org"
alt="" class="" width="205" height="118"><br>
</p>
<p>alpha 100% <img src="cid:part3.04F06235.2AA08B08@kdenlive.org"
alt="" class="" width="205" height="118"></p>
<p>So, no rocket science here. Just plain multi-track compositing
to get things done.<br>
</p>
<p>Head over to 19.04, same project loaded; but you achieve the
same results when you recreate from scratch. It doesn't look
like an import issue, and in fact I've found out when working on
a fresh 19.04 project from scratch.<br>
</p>
<p><img src="cid:part4.392AD67C.027A7350@kdenlive.org" alt=""
class=""></p>
<p><br>
</p>
<p>alpha 50% <img src="cid:part5.C1391DED.4279136D@kdenlive.org"
alt="" class="" width="168" height="95"> ... seems to like
fine on a first glimpse, but the compositing is already
different, so compare the last frame of the fade in c&t.<br>
</p>
<p>alpha 100% <img src="cid:part6.DDE0EB1A.4237AB17@kdenlive.org"
alt="" class="" width="181" height="102"> ... no, this doesn't
make sense at all.</p>
<p>First frame after the V4/V5 transitions ended: <img
src="cid:part7.03E781AE.0C6684FC@kdenlive.org" alt="" class=""
width="189" height="107"> ... this is correct, so the previous
frame should have (almost) reached this.<br>
</p>
<p>I've tried this on this day's <a
href="https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/kdenlive-19.04.1-dfe2c78-x86_64.appimage"
moz-do-not-send="true">kdenlive-19.04.1-dfe2c78-x86_64.appimage</a>.<br>
</p>
<p>So why did you change multitrack timeline compositing? What
compelling reason is there to do so? And what sense does it make
considering my example showing that the explicit transitions
behave totally different from the implicit transitions, as
opposed to behavior of the long-term stable Kdenlive series?</p>
<p>A stopgap measure is to throw in lots of unnecessary
transitions to basically override the implicit transitions
almost everywhere. But seriously, that cannot be a rationale for
user experience for a refactored product, can it?<br>
</p>
<p>Harald</p>
<p><br>
</p>
</blockquote>
</body>
</html>