example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before

Thu May 9 22:06:14 BST 2019

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.noise at gmail.com> Datum: 09.05.19  21:00  (GMT+01:00) An: Kdenlive <kdenlive at kde.org> Betreff: Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before Hi HaraldLet 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.albrecht at 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.
    
    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! 
    
    HaraldCheers :D -- 1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومةfsf member #5439usuario 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/4c2c4c38/attachment-0001.html>