I think that you would have a better time getting responses from people if you didn't act so entitled and antagonistic.
>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. And yet you come to this mailing list asking for help? Do you even want answers? lol >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. If you're such a smart 600 IQ genius programmer, why didn't you fix this problem yourself and contribute to the program? On 2019-05-09 3:06 p.m., harald.albrecht wrote: > 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. > > 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. > > Harald. > > > -------- Ursprüngliche Nachricht -------- > Von: farid abdelnour <snd.no...@gmail.com> > Datum: 09.05.19 21:00 (GMT+01:00) > An: Kdenlive <kdenlive@kde.org> > Betreff: Re: example project: 19.04 Multitrack compositing still broken: > differs from all previous Kdenlive versions back to 15 and before > > Hi Harald > > 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... > > Em qua, 8 de mai de 2019 às 14:43, Harald Albrecht > <harald.albre...@gmx.net <mailto:harald.albre...@gmx.net>> escreveu: > > 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. > > > 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. > > 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. > > 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. > > > 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. > > 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). > > 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. > > 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... > > 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. > > > No one from the devs team feels that! > > *** > > 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". > > The V2->V1 composite&transform is just for a fade in with an alpha > ramp from 0% to 100%. > > 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. > > alpha 50% > > alpha 100% > > So, no rocket science here. Just plain multi-track compositing to > get things done. > > 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. > > > alpha 50% ... 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. > > alpha 100% ... no, this doesn't make sense at all. > > First frame after the V4/V5 transitions ended: ... this is correct, > so the previous frame should have (almost) reached this. > > I've tried this on this day's > kdenlive-19.04.1-dfe2c78-x86_64.appimage > > <https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/kdenlive-19.04.1-dfe2c78-x86_64.appimage>. > > 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? > > 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? > > > 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! > > > Harald > > > Cheers :D > > > -- > 1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة > fsf member #5439 > usuario GNU/Linux #471966 > |_|0|_| > |_|_|0| > |0|0|0| > <a href="http://www.gunga.com.br";>gunga</a> > <a href="http://www.tempoecoarte.com.br";>tempoecoarte</a> > <a href="http://www.atelier-labs.org";>atelier-labs</a> > <a href="http://www.mocambos.net";>rede mocambos</a>
<<attachment: patrickrogers.vcf>>
signature.asc
Description: OpenPGP digital signature
