<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 10 mai 2019 à 01:20, Jacob Kauffmann <<a href="mailto:jacob@nerdonthestreet.com">jacob@nerdonthestreet.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><blockquote type="cite"><div>Could you describe specifically what is "slow" here? The preview? Moving clips around?<br></div></blockquote><div><br></div><div>Making cuts! It seems that after the refactor, when I make a cut (using Cut Clip bound to a keyboard shortcut), Kdenlive wants to re-calculate the waveform of the new clip <i>after</i> the cut (the new clip <i>before</i> the cut does not re-calculate its waveform.) What I've found is that the longer the remaining clip is, the longer it takes to recalculate the waveform, and the interface is visually frozen while it's recalculating (i.e. I can't click and drag clips around until it's done with the waveform recalculation.) My workaround right now is to start off my edit by making a random cut about once every 25 minutes, which means it doesn't take as long to recalculate the clip after the cut, because it only gets shorter from the 25 minute chunks I start with. Still, a lot of my recordings are 45 minutes to an hour long (or longer), and I make <i>hundreds</i> of cuts to get that time cut down, so having to do this is a little annoying compared to previous versions of Kdenlive, when cutting was instantaneous regardless of any other factor.<br></div><div><br></div><div>One important observation I've noticed when reproducing the issue just now was that it's only a noticeable problem when I'm very zoomed in on the timeline (which I almost always am, because I make a lot of single-frame adjustments when I'm making cuts.) The more zoomed in I am, the longer it takes for the waveform to come back and for Kdenlive to become responsive again after I make a cut. (Pre-refactor versions of Kdenlive didn't seem to care how zoomed in I was; it never affected performance.)<br></div></div></blockquote><div> </div><div>Ah, I see! Well yeah we have a lot of room of improvement for the performance of the wave-form I think. I opened a ticket here (<a href="https://invent.kde.org/kde/kdenlive/issues/181" target="_blank">https://invent.kde.org/kde/kdenlive/issues/181</a>). As a workaround, you can (temporarily) disable the display of the wave-forms in your settings if you don't need at some point during your editing process (and then turn them back later). </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div><br></div><blockquote type="cite"><div>The compositing bug, while frustrating, falls into the "bug" category and not in the "crazy stupid changes these morons did just to blow up my workflow and get me insane" category<br></div></blockquote><div><br></div><div>With respect, comparisons like this only serve to make people feel like you're belittling their concerns. Even when users overreact (and keep in mind that I was <i>not</i> the one who started this chain!), you have to understand that my thought process isn't "oh, they changed how xyz code works, of <i>course</i> the program is way slower on my high-end machine." It's more like "they had this specific thing working perfectly fine before, they fixed some bugs somewhere else but why would they do it in a way that slows the entire program down?" Of course, I know it's all complicated and that's why I don't go around sending emails complaining every time I have an issue, I'm just saying that there is more than one valid perspective here and I think that disconnect is part of what upset Harald.<br></div></div></blockquote><div><br></div><div>Sure, this remark was not addressed to you specifically :) What I want to emphasize is that users and developers ultimately have the same goal: making the software as good as possible. Now, progress is never linear, and we are grateful to the community to join us on this great journey, even though sometimes things are not ideal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div><br></div><blockquote type="cite"><div>As for the "few other issues", I invite you to submit them here <a href="https://invent.kde.org/kde/kdenlive/issues" target="_blank">https://invent.kde.org/kde/kdenlive/issues</a>.<br></div></blockquote><div><br></div><div>I'll be honest, I've been using KDE software for a long time, and I've never heard of <a href="http://invent.kde.org" target="_blank">invent.kde.org</a> before. The "Bug reports" page on <a href="http://kdenlive.org" target="_blank">kdenlive.org</a> (at <a href="https://kdenlive.org/en/bug-reports/" target="_blank">https://kdenlive.org/en/bug-reports/</a>) points to <a href="http://bugs.kde.org" target="_blank">bugs.kde.org</a>, which I monitor fairly regularly for Kdenlive and several other projects. <a href="http://Invent.kde.org" target="_blank">Invent.kde.org</a> looks much more modern (it looks like a GitLab deployment, I remember hearing something about that a while ago); is this a replacement for <a href="http://bugs.kde.org" target="_blank">bugs.kde.org</a>, or some kind of alternative/supplement? (It also has source code, so how does it relate to <a href="http://cgit.kde.org" target="_blank">cgit.kde.org</a>?)<br></div></div></blockquote><div><br></div><div>Kdenlive has now fully moved to gitlab for the development. <a href="http://bugs.kde.org/" target="_blank">bugs.kde.org</a> is still monitored, but I think all the developers prefer the gitlab interface. The downside is that you need a kde identity account to open an issue, which creates more friction than <a href="http://bugs.kde.org/" target="_blank">bugs.kde.org</a> (where if I'm not mistaken it's easier to create an account). In practice, when a bug from <a href="http://bugs.kde.org/" target="_blank">bugs.kde.org</a> is confirmed, we usually open a mirror issue on the gitlab. <br></div><div> As far as Kdenlive is concerned, <a href="http://cgit.kde.org/" target="_blank">cgit.kde.org</a> is not used anymore, and acts only as a mirror.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div><br></div><div>As far as reporting bugs goes, I use Arch Linux which means I don't have debug symbols by default, and most of the issues I have also don't result in hard crashes, which means I don't have much technical detail to show. I'm always wary of annoying devs with descriptions of issues but nothing to point to the actual problem in the code. However, I'll go ahead and submit at least one of the other issues I'm running into, if I can't find them in the list of open issues already.<br></div></div></blockquote><div><br></div><div>If you are not reporting crashes, the debug symbols don't make any difference, don't let that stop you :)</div><div>And even if you are, knowing that there is a crash somewhere is valuable. Here are some general guidelines for good reports:</div><div><ul><li>Try to see if you are not reporting a duplicate (this can be hard since we have several reporting channels, but at least look at the list of issues in the channel you choose to submit to)</li><li>Make sure it doesn't happen in the latest version (the reference for it being the nightly appimage available here <a href="https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/" target="_blank">https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/</a>)</li><li>Describe the steps to reproduce the bug (a video can be very helpful for this)</li><li>If applicable, it sometimes help to have a project file that triggers the bug (say if it doesn't occur from a blank project)</li></ul></div><div>Every feedback is a gift, don't hesitate to report anything that bothers you :)</div><div><br></div><div>Cheers! </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div></div><div><br></div><div>Thanks for your response!<br></div><div><br></div><div>- Jacob Kauffmann<br></div><div><br></div><div>On Thu, May 9, 2019, at 5:02 PM, alcinos wrote:<br></div><blockquote type="cite" id="gmail-m_-6594825188636927774qt"><div dir="ltr"><div dir="ltr"><br></div><div><br></div><div class="gmail-m_-6594825188636927774qt-gmail_quote"><div class="gmail-m_-6594825188636927774qt-gmail_attr" dir="ltr">Le jeu. 9 mai 2019 à 23:40, Jacob Kauffmann <<a href="mailto:jacob@nerdonthestreet.com" target="_blank">jacob@nerdonthestreet.com</a>> a écrit :<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail-m_-6594825188636927774qt-gmail_quote"><div><u></u><br></div><div><div>As another user, I'd just like to say that Farid's response here was fairly reassuring at least, and I'm glad Harald started this thread because I got to read Farid's response. I usually can't make the Cafe's, and I haven't found them super productive when I have listened in on them, but I think the Kdenlive "community" (userbase) is starting to reach the size where devs will see angry users when things break. I know I've personally thought to myself "what in the world are the developers doing?" several times since upgrading to the stable refactored version, but as long as they follow up on what they're saying in terms of continuing to polish (rather than calling this "finished"), I have faith the software will be better for it and I'm very thankful to the developers for spending their time and effort on this important project.<br></div></div></blockquote><div><br></div><div>Thank you for your kind words. <br></div><div>Change always generate friction. There are bugs that will creep in, no matter how careful we are, but more fundamentally, major changes will have impact on people's habits, and that can be frustrating ("but the old way worked for me" "I don't have time to learn a new workflow, I need to finish this project soon"). <br></div><div>We hope that the users cope with us and eventually find themselves more productive, because this is obviously the goal driving our decisions, with a lot of consulting from the community. Obviously, we are human, thus make mistakes and we will always stay open to feedback and incorporate it if it makes sense.<br></div><div>The compositing bug, while frustrating, falls into the "bug" category and not in the "crazy stupid changes these morons did just to blow up my workflow and get me insane" category (notice the slight nuance here). As we speak, this bug as already been fixed by JB, who is, as always, super reactive.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail-m_-6594825188636927774qt-gmail_quote"><div><div><br></div><div><br></div><div>With regards to changes, nobody is stopping anyone from using old versions of the AppImage or other installations, so if the current "stable" is not stable enough (which is always unfortunate to acknowledge, but is often the case with Kdenlive), people can always keep using an earlier version if it's working for them. Personally, I've found that the new version is <i>incredibly</i> slow with long (45-minute+) clips in the timeline, along with a few other issues, but the much-improved stability of the keyframing system and the lower criticality of timeline corruption is worth putting up with the quirks for the time being, in my case.<br></div></div></blockquote><div><br></div><div>Could you describe specifically what is "slow" here? The preview? Moving clips around?<br></div><div>As for the "few other issues", I invite you to submit them here <a href="https://invent.kde.org/kde/kdenlive/issues" target="_blank">https://invent.kde.org/kde/kdenlive/issues</a>. We can only fix issues if we are aware of them :)<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail-m_-6594825188636927774qt-gmail_quote"><div><div><br></div><div><br></div><div>Older AppImages are still available for download right alongside the newest one, all the way back to 16.12.2: <a href="https://files.kde.org/kdenlive/release/" target="_blank">https://files.kde.org/kdenlive/release/</a> (Are the regressions worth the improvements? Decide for yourself and pick your poison.)<br></div><div><br></div><div>- Jacob Kauffmann<br></div><div><br></div><div>On Thu, May 9, 2019, at 4:06 PM, harald.albrecht wrote:<br></div><blockquote id="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt" type="cite"><div>I notice that my reason for speaking up is unfortunately not getting through, and that is, in my opinion, due to solely focusing on the developers refactoring task and the primary goal of stability, where stability has different semantica for devs and for different users. As a user I value stability across releases, that functions work as learnt and used. Of course, values differ.<br></div><div><br></div><div>Any tonal issues are easily solved now, as I stop stepping forward here or engaging again, raising issues and asking for reason why things get changed. My need for a NLVE is as described and this doesn't seem to be Kdenlive's roadmap. That's fine, so let's end this here. There's no common understanding and no sign that it might happen, no pun. It's your community.<br></div><div><br></div><div>Harald.<br></div><div><br></div><div><br></div><div style="font-size:100%;color:rgb(0,0,0)"><div>-------- Ursprüngliche Nachricht --------<br></div><div>Von: farid abdelnour <<a href="mailto:snd.noise@gmail.com" target="_blank">snd.noise@gmail.com</a>><br></div><div>Datum: 09.05.19 21:00 (GMT+01:00)<br></div><div>An: Kdenlive <<a href="mailto:kdenlive@kde.org" target="_blank">kdenlive@kde.org</a>><br></div><div>Betreff: Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before<br></div><div><br></div></div><div dir="ltr"><div dir="ltr"><div>Hi Harald<br></div><div><br></div><div>Let me start by saying how much I think you are a valuable member to
this community (see the Toolbox among many other things) and I think the
devs feel the same. I just cannot but help to dislike your tone.
Although I can TOTALLY understand your frustration with seeing your
daily driver not work. Maybe because i follow the difficulties of
develoipment on a day to day basis...<br></div><div><br></div></div><div class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_quote"><div dir="ltr" class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_attr">Em qua, 8 de mai de 2019 às 14:43, Harald Albrecht <<a href="mailto:harald.albrecht@gmx.net" target="_blank">harald.albrecht@gmx.net</a>> escreveu:<br></div><blockquote class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><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></div></blockquote><div> <br></div><div>We really tested as much as we could the code, but weren't able to catch everything, this is why in the release notes we stated that we will focus this whole 19.04 cycle to finish polishing things. Compositing somehow broke during this code change, I didn't notice that during my tests, but as far as I know JB already fixed it. Unfortunately I cannot give you a clue as to why it happened, but it did and it is now fixed. The good thing now is that fixing things is much quicker. <br></div><div><br></div><blockquote class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p><br></p><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></div></blockquote><div>During the process the focus was on stabilizing things. Now is the time to focus of fixing stuff that broke during the code change, that is probably why you might have gotten such answer (don't know really). About the thing being "your fault" it was a community member trying to help out as he couldn't reproduce your issue. I don't think the intention was to blame you or to discredit you. It was in good faith.<br></div><div> <br></div><blockquote class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><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></div></blockquote><div>I really cannot tell when you felt a "get off my lawn" attitude, most of the café yesterday was spent to hear your feedback and JBM fixed many issues as you were reporting them. <br></div><div><br></div><div>I here state for you and everyone reading that we are a community and not a one person project. We value and want to listen feedback from everyone. At least I hope you see this from the website posts, the cafés and everything else... <br></div><blockquote class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><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></div></blockquote><div><br></div><div>No one from the devs team feels that! <br></div><blockquote class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p><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 alt=""><br></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 alt="" width="205" height="118"><br></p><p>alpha 100% <img alt="" width="205" height="118"><br></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 alt=""><br></p><p><br></p><p>alpha 50% <img alt="" 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 alt="" width="181" height="102"> ... no, this doesn't make sense at
all.<br></p><p>First frame after the V4/V5 transitions ended: <img alt="" 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" target="_blank">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?<br></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></div></blockquote><div><br></div><div>I am sure the devs will fix everything you point to that is broken, I just ask you to have (more) patience if things sometimes don't work. If you have energy report themWe are gettng there!<br></div><div> <br></div><blockquote class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><p><br></p><p>Harald<br></p></div></blockquote><div><br></div><div>Cheers :D <br></div></div><div><br></div><div><br></div><div>-- <br></div><div dir="ltr" class="gmail-m_-6594825188636927774qt-gmail-m_1708856174368002732qt-gmail_signature"><div>1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة<br></div><div>fsf member #5439<br></div><div>usuario GNU/Linux #471966<br></div><div>|_|0|_|<br></div><div>|_|_|0|<br></div><div>|0|0|0|<br></div><div><a href="<a href="http://www.gunga.com.br" target="_blank">http://www.gunga.com.br</a>">gunga</a><br></div><div><a href="<a href="http://www.tempoecoarte.com.br" target="_blank">http://www.tempoecoarte.com.br</a>">tempoecoarte</a><br></div><div><a href="<a href="http://www.atelier-labs.org" target="_blank">http://www.atelier-labs.org</a>">atelier-labs</a><br></div><div><a href="<a href="http://www.mocambos.net" target="_blank">http://www.mocambos.net</a>">rede mocambos</a><br></div></div></div></blockquote><div><br></div></div></blockquote></div></div></blockquote><div><br></div></div></blockquote></div></div>