From camille.moulin at free.fr  Wed May  1 11:19:45 2019
From: camille.moulin at free.fr (Camille Moulin)
Date: Wed, 1 May 2019 12:19:45 +0200
Subject: Timeline Scrub + Zoom Feature?
In-Reply-To: <CAHmPLWVcd9Rjaj_BbJoToFhPRHenUk1fx7XUji3B7RmSeL9eBA@mail.gmail.com>
References: <CAHmPLWVcd9Rjaj_BbJoToFhPRHenUk1fx7XUji3B7RmSeL9eBA@mail.gmail.com>
Message-ID: <cfa74957-6980-5b75-6b88-e65c3637d41b@free.fr>

Hi Antony,

On 30/04/2019 12:55, Anthony Walter wrote:
> Would it be possible for the development team to consider adding this
> feature?
>
> https://cache.getlazarus.org/videos/video-zooming.mp4
>
> The feature above allows scrollbars in several areas to be used both
> for zooming and scrubbing through timelines. It also shows you at a
> glance the length of a clip or sequence.

This is a great feature IMHO : it  was present in the defunct Open Movie
Editor and I found it most convenient at the time.

> With this feature you can change the zoom level of a timeline by
> simply dragging at either end of a scroll associated with a timeline,
> or scrub through the timeline by clicking and dragging a scrollbar in
> the middle.
>
> If this feature was considered before and rejected, would you be
> considerate enough to recap how that decision was arrived at?

I don't think it has been submitted before. Does anyone remember?

[..]

Best,

Camille



From snd.noise at gmail.com  Mon May  6 18:47:00 2019
From: snd.noise at gmail.com (farid abdelnour)
Date: Mon, 6 May 2019 14:47:00 -0300
Subject: =?UTF-8?Q?Kdenlive_Caf=C3=A9_tomorrow?=
Message-ID: <CAHMxv37muZfmYQbjZ2u+mqksnRGaN9hEobmLqPcQNXybiotxnQ@mail.gmail.com>

The first Kdenlive Café after the release of the refactored code will be
held this Tuesday 7th of May at 9PM CEST. We will dedicate the first slot
of the meeting to listen to the community’s reaction and answer any doubts
or issues you might have. As usual we’ll be at #kdenlive on IRC and the
Kdenlive Telegram group.

See you!


-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190506/657e13fa/attachment.html>

From dougpol2 at gmail.com  Tue May  7 16:02:01 2019
From: dougpol2 at gmail.com (Douglas Pollard)
Date: Tue, 7 May 2019 11:02:01 -0400
Subject: How to get Top toolbar back
Message-ID: <7ad07040-5142-619b-2a67-8726668ec3ab@Gmail.com>

Lost  the very top bar that contains permissions  and such I don't know 
the name of it.   I have done this before but don't remember how I got 
it back can't make video with out it. Thanks for any help,  Douglas Pollard.


From snd.noise at gmail.com  Tue May  7 16:05:52 2019
From: snd.noise at gmail.com (farid abdelnour)
Date: Tue, 7 May 2019 12:05:52 -0300
Subject: How to get Top toolbar back
In-Reply-To: <7ad07040-5142-619b-2a67-8726668ec3ab@Gmail.com>
References: <7ad07040-5142-619b-2a67-8726668ec3ab@Gmail.com>
Message-ID: <CAHMxv37Qa8fkQ1O0nw+2G4SRqYjMwXg7RAd4VbLQeD3rnh-tqQ@mail.gmail.com>

hi

press ctrl + m

Em ter, 7 de mai de 2019 às 12:02, Douglas Pollard <dougpol2 at gmail.com>
escreveu:

> Lost  the very top bar that contains permissions  and such I don't know
> the name of it.   I have done this before but don't remember how I got
> it back can't make video with out it. Thanks for any help,  Douglas
> Pollard.
>
>

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190507/bb860daf/attachment.html>

From dougpol2 at gmail.com  Wed May  8 16:54:15 2019
From: dougpol2 at gmail.com (Douglas Pollard)
Date: Wed, 8 May 2019 11:54:15 -0400
Subject: Can't render
Message-ID: <52869fa2-d721-ac9b-2856-83c0581cf717@Gmail.com>

I have a Video of one video to timeline and one audio line. I had 
started to put pictures and video on a third time line Kdenlive 
crashed.  I went to Open recent to restart as my video did not come up 
on timeline or clips. I used a  tried a couple back up clips and they 
made video but still would not  render.   I used proxy-clips set to 500 
video and 500 audio. After five attempts to render I wound up with 4 new 
recent titles all of them will play but will not render. In some moments 
of frustration I decided to give up on Kdenlive and deleted the program 
and after thinking about a few hours. I changed my mind  so downloaded 
Kdenlive again using Software  manager and flatpack. Installed my files 
again using couple backup files. Still will not render but sure like the 
new Kdenlive .   I have to add here that in a few weeks I will be 84 
years old and having doubts that I am still able to do video at all. I 
really hope that is not the case as I enjoy it and now have 82  videos  
on You tube. I have never j had a problem  Rendering before, so maybe I 
am about to learn a new trick? Sorry for writing a book. Thanks, Doug


From informatica at actiu.net  Wed May  8 17:07:09 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Wed, 8 May 2019 18:07:09 +0200
Subject: Can't render
In-Reply-To: <52869fa2-d721-ac9b-2856-83c0581cf717@Gmail.com>
Message-ID: <188f1d2a-701b-fefc-94d5-ba940eb534a2@actiu.net>

Please, provide:
- Operating system and version
- Kdenlive version and architecture
- Video clips format, length and file size

El 8/5/19 a les 17:54, Douglas Pollard ha escrit:
> I have a Video of one video to timeline and one audio line. I had
> started to put pictures and video on a third time line Kdenlive
> crashed.  I went to Open recent to restart as my video did not come up
> on timeline or clips. I used a  tried a couple back up clips and they
> made video but still would not  render.   I used proxy-clips set to 500
> video and 500 audio. After five attempts to render I wound up with 4 new
> recent titles all of them will play but will not render. In some moments
> of frustration I decided to give up on Kdenlive and deleted the program
> and after thinking about a few hours. I changed my mind  so downloaded
> Kdenlive again using Software  manager and flatpack. Installed my files
> again using couple backup files. Still will not render but sure like the
> new Kdenlive .   I have to add here that in a few weeks I will be 84
> years old and having doubts that I am still able to do video at all. I
> really hope that is not the case as I enjoy it and now have 82  videos 
> on You tube. I have never j had a problem  Rendering before, so maybe I
> am about to learn a new trick? Sorry for writing a book. Thanks, Doug
> 

From informatica at actiu.net  Wed May  8 17:44:29 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Wed, 8 May 2019 18:44:29 +0200
Subject: Fwd: Can't render
In-Reply-To: <a25338c9-70a0-748c-28d0-c1fd541d5cd1@Gmail.com>
Message-ID: <2efd437b-f222-7b35-a01d-990b9e9bbf2b@actiu.net>

-------- Missatge reenviat --------
Assumpte: Re: Can't render
Data: Wed, 8 May 2019 12:31:07 -0400
De: Douglas Pollard <dougpol2 at gmail.com>
A: Narcis Garcia <informatica at actiu.net>

I am using Mint 19.1 Tesa, 64 bit,   Kden Live 19.04.0, My video clips
are from canon camera MP4 1080 Not sure where to find file size but the
video is 17minutes long.  I will look for file size. Doug


On 5/8/19 12:07 PM, Narcis Garcia wrote:
> Please, provide:
> - Operating system and version
> - Kdenlive version and architecture
> - Video clips format, length and file size
>
> El 8/5/19 a les 17:54, Douglas Pollard ha escrit:
>> I have a Video of one video to timeline and one audio line. I had
>> started to put pictures and video on a third time line Kdenlive
>> crashed.  I went to Open recent to restart as my video did not come up
>> on timeline or clips. I used a  tried a couple back up clips and they
>> made video but still would not  render.   I used proxy-clips set to 500
>> video and 500 audio. After five attempts to render I wound up with 4 new
>> recent titles all of them will play but will not render. In some moments
>> of frustration I decided to give up on Kdenlive and deleted the program
>> and after thinking about a few hours. I changed my mind  so downloaded
>> Kdenlive again using Software  manager and flatpack. Installed my files
>> again using couple backup files. Still will not render but sure like the
>> new Kdenlive .   I have to add here that in a few weeks I will be 84
>> years old and having doubts that I am still able to do video at all. I
>> really hope that is not the case as I enjoy it and now have 82  videos
>> on You tube. I have never j had a problem  Rendering before, so maybe I
>> am about to learn a new trick? Sorry for writing a book. Thanks, Doug
>>

From informatica at actiu.net  Wed May  8 17:44:40 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Wed, 8 May 2019 18:44:40 +0200
Subject: Fwd: Can't render
In-Reply-To: <9578d101-7193-77dd-09b8-d741cf6979e1@Gmail.com>
Message-ID: <78d3a037-77eb-cab8-e89a-7b8c52f8bee7@actiu.net>

-------- Missatge reenviat --------
Assumpte: Re: Can't render
Data: Wed, 8 May 2019 12:38:07 -0400
De: Douglas Pollard <dougpol2 at gmail.com>
A: Narcis Garcia <informatica at actiu.net>

Also My computer is HP Elite Desktop with 16 gigs Memory

Dual core    Doug


On 5/8/19 12:31 PM, Douglas Pollard wrote:
> I am using Mint 19.1 Tesa, 64 bit,   Kden Live 19.04.0, My video clips 
> are from canon camera MP4 1080 Not sure where to find file size but 
> the video is 17minutes long.  I will look for file size. Doug
>
>
> On 5/8/19 12:07 PM, Narcis Garcia wrote:
>> Please, provide:
>> - Operating system and version
>> - Kdenlive version and architecture
>> - Video clips format, length and file size
>>
>> El 8/5/19 a les 17:54, Douglas Pollard ha escrit:
>>> I have a Video of one video to timeline and one audio line. I had
>>> started to put pictures and video on a third time line Kdenlive
>>> crashed.  I went to Open recent to restart as my video did not come up
>>> on timeline or clips. I used a  tried a couple back up clips and they
>>> made video but still would not  render.   I used proxy-clips set to 500
>>> video and 500 audio. After five attempts to render I wound up with 4 
>>> new
>>> recent titles all of them will play but will not render. In some 
>>> moments
>>> of frustration I decided to give up on Kdenlive and deleted the program
>>> and after thinking about a few hours. I changed my mind  so downloaded
>>> Kdenlive again using Software  manager and flatpack. Installed my files
>>> again using couple backup files. Still will not render but sure like 
>>> the
>>> new Kdenlive .   I have to add here that in a few weeks I will be 84
>>> years old and having doubts that I am still able to do video at all. I
>>> really hope that is not the case as I enjoy it and now have 82  videos
>>> on You tube. I have never j had a problem  Rendering before, so maybe I
>>> am about to learn a new trick? Sorry for writing a book. Thanks, Doug
>>>

From harald.albrecht at gmx.net  Wed May  8 18:42:47 2019
From: harald.albrecht at gmx.net (Harald Albrecht)
Date: Wed, 8 May 2019 19:42:47 +0200
Subject: example project: 19.04 Multitrack compositing still broken: differs
 from all previous Kdenlive versions back to 15 and before
Message-ID: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>

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.

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.

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).

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.

***

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?

Harald


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bnfdgmkmphlpinlc.png
Type: image/png
Size: 33535 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kkhnlmafhidelmgh.png
Type: image/png
Size: 5538 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfpiknjpkigmkjpe.png
Type: image/png
Size: 5412 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgpabbbnjcnaofff.png
Type: image/png
Size: 45154 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdcehakombfedldb.png
Type: image/png
Size: 4381 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kojfbpgdjaoejjnb.png
Type: image/png
Size: 2321 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpadjfpjgpmiinma.png
Type: image/png
Size: 4460 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: track-compositing-test-old-stable.kdenlive
Type: application/x-kdenlive
Size: 15630 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190508/01fbb3c1/attachment-0001.bin>

From harald.albrecht at gmx.net  Wed May  8 18:48:39 2019
From: harald.albrecht at gmx.net (Harald Albrecht)
Date: Wed, 8 May 2019 19:48:39 +0200
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
References: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
Message-ID: <a3f9d268-1011-4a69-8832-cc2cc5fb684f@gmx.net>

wait ... you did even change the *order* in which explicit transitions
get applied? So the V5->V1 transition gets processed before V4->V1, so
the V5 title text ends up below the V4 title bar? This would explain why
the text fades out when it should fade in and why the sudden change at
the end of the V5/V4 transitions.

Now that's creative compositing.




From eugen.mohr at gmx.net  Wed May  8 19:06:38 2019
From: eugen.mohr at gmx.net (Eugen Mohr)
Date: Wed, 8 May 2019 20:06:38 +0200
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <a3f9d268-1011-4a69-8832-cc2cc5fb684f@gmx.net>
References: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
 <a3f9d268-1011-4a69-8832-cc2cc5fb684f@gmx.net>
Message-ID: <c3f1b7a7-849a-745f-073e-6353cdadd3f5@gmx.net>

Hi Harald

I think this is the same issue then here in the bugtracker:
https://bugs.kde.org/show_bug.cgi?id=407077#c7

Merlimau


Am 08.05.2019 um 19:48 schrieb Harald Albrecht:
> wait ... you did even change the *order* in which explicit transitions
> get applied? So the V5->V1 transition gets processed before V4->V1, so
> the V5 title text ends up below the V4 title bar? This would explain why
> the text fades out when it should fade in and why the sudden change at
> the end of the V5/V4 transitions.
>
> Now that's creative compositing.
>
>
>
>

From informatica at actiu.net  Thu May  9 09:07:29 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Thu, 9 May 2019 10:07:29 +0200
Subject: Fwd: Fwd: Can't render
In-Reply-To: <07292780-3b3e-3cd8-7138-e716cfb9c955@Gmail.com>
Message-ID: <72101e25-4052-ad92-fe9e-92776dd7f6b1@actiu.net>

[reply to mailing list please]


-------- Missatge reenviat --------
Assumpte: Re: Fwd: Can't render
Data: Wed, 8 May 2019 15:00:29 -0400
De: Douglas Pollard <dougpol2 at gmail.com>
A: Narcis Garcia <informatica at actiu.net>

Well Narcis I just

i found an invalid file among my video files I Deleted it and kdenlive
is rendering. It's not finished yet but I think it will be OK.
The questions you asked prompted me to go through again  everything
including the video files I was using. Hadn't seen it before.
 So problem solved. Thank you so much, Douglas Pollard  Got some
 learning to do to catch up with the changes in Kdenlive but I like what
I am seeing.


On 5/8/19 12:44 PM, Narcis Garcia wrote:
> -------- Missatge reenviat --------
> Assumpte: Re: Can't render
> Data: Wed, 8 May 2019 12:38:07 -0400
> De: Douglas Pollard <dougpol2 at gmail.com>
> A: Narcis Garcia <informatica at actiu.net>
>
> Also My computer is HP Elite Desktop with 16 gigs Memory
>
> Dual core    Doug
>
>
> On 5/8/19 12:31 PM, Douglas Pollard wrote:
>> I am using Mint 19.1 Tesa, 64 bit,   Kden Live 19.04.0, My video clips
>> are from canon camera MP4 1080 Not sure where to find file size but
>> the video is 17minutes long.  I will look for file size. Doug
>>
>>
>> On 5/8/19 12:07 PM, Narcis Garcia wrote:
>>> Please, provide:
>>> - Operating system and version
>>> - Kdenlive version and architecture
>>> - Video clips format, length and file size
>>>
>>> El 8/5/19 a les 17:54, Douglas Pollard ha escrit:
>>>> I have a Video of one video to timeline and one audio line. I had
>>>> started to put pictures and video on a third time line Kdenlive
>>>> crashed.  I went to Open recent to restart as my video did not come up
>>>> on timeline or clips. I used a  tried a couple back up clips and they
>>>> made video but still would not  render.   I used proxy-clips set to 500
>>>> video and 500 audio. After five attempts to render I wound up with 4
>>>> new
>>>> recent titles all of them will play but will not render. In some
>>>> moments
>>>> of frustration I decided to give up on Kdenlive and deleted the program
>>>> and after thinking about a few hours. I changed my mind  so downloaded
>>>> Kdenlive again using Software  manager and flatpack. Installed my files
>>>> again using couple backup files. Still will not render but sure like
>>>> the
>>>> new Kdenlive .   I have to add here that in a few weeks I will be 84
>>>> years old and having doubts that I am still able to do video at all. I
>>>> really hope that is not the case as I enjoy it and now have 82  videos
>>>> on You tube. I have never j had a problem  Rendering before, so maybe I
>>>> am about to learn a new trick? Sorry for writing a book. Thanks, Doug
>>>>

From snd.noise at gmail.com  Thu May  9 20:00:15 2019
From: snd.noise at gmail.com (farid abdelnour)
Date: Thu, 9 May 2019 16:00:15 -0300
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
References: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
Message-ID: <CAHMxv37jNve=Zi+QAPrxF1HN06AmJx2ZDrONzf0prOf6J8Kg-A@mail.gmail.com>

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.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
> <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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bnfdgmkmphlpinlc.png
Type: image/png
Size: 33535 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kkhnlmafhidelmgh.png
Type: image/png
Size: 5538 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfpiknjpkigmkjpe.png
Type: image/png
Size: 5412 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgpabbbnjcnaofff.png
Type: image/png
Size: 45154 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdcehakombfedldb.png
Type: image/png
Size: 4381 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kojfbpgdjaoejjnb.png
Type: image/png
Size: 2321 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpadjfpjgpmiinma.png
Type: image/png
Size: 4460 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/018efb68/attachment-0013.png>

From harald.albrecht at gmx.net  Thu May  9 22:06:14 2019
From: harald.albrecht at gmx.net (harald.albrecht)
Date: Thu, 09 May 2019 23:06:14 +0200
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <f36srltqec3jb6t2baofj5uo.1557434242966@email.android.com>
Message-ID: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>

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>

From jacob at nerdonthestreet.com  Thu May  9 22:38:23 2019
From: jacob at nerdonthestreet.com (Jacob Kauffmann)
Date: Thu, 09 May 2019 17:38:23 -0400
Subject: =?UTF-8?Q?Re:_example_project:_19.04_Multitrack_compositing_still_broken?=
 =?UTF-8?Q?:_differs_from_all_previous_Kdenlive_versions_back_to_15_and_?=
 =?UTF-8?Q?before?=
In-Reply-To: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
Message-ID: <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>

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.

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 *incredibly* 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.

Older AppImages are still available for download right alongside the newest one, all the way back to 16.12.2: https://files.kde.org/kdenlive/release/ (Are the regressions worth the improvements? Decide for yourself and pick your poison.)

- Jacob Kauffmann

On Thu, May 9, 2019, at 4:06 PM, 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.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 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.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 <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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/df5479c6/attachment-0001.html>

From patrickrogers at national.shitposting.agency  Thu May  9 22:55:38 2019
From: patrickrogers at national.shitposting.agency (Patrick Rogers)
Date: Thu, 9 May 2019 15:55:38 -0600
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
Message-ID: <b51d3047-69e1-ed10-f90b-a5039c0fbf14@national.shitposting.agency>

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.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 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.albrecht at gmx.net <mailto: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
>     <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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patrickrogers.vcf
Type: text/x-vcard
Size: 357 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/a065232f/attachment.vcf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/a065232f/attachment.sig>

From french.ebook.lover at gmail.com  Thu May  9 23:02:08 2019
From: french.ebook.lover at gmail.com (alcinos)
Date: Fri, 10 May 2019 00:02:08 +0200
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
Message-ID: <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>

Le jeu. 9 mai 2019 à 23:40, Jacob Kauffmann <jacob at nerdonthestreet.com> a
écrit :

> 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.
>

Thank you for your kind words.
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").
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.
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.


>
> 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
> *incredibly* 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.
>

Could you describe specifically what is "slow" here? The preview? Moving
clips around?
As for the "few other issues", I invite you to submit them here
https://invent.kde.org/kde/kdenlive/issues. We can only fix issues if we
are aware of them :)


>
> Older AppImages are still available for download right alongside the
> newest one, all the way back to 16.12.2:
> https://files.kde.org/kdenlive/release/ (Are the regressions worth the
> improvements? Decide for yourself and pick your poison.)
>
> - Jacob Kauffmann
>
> On Thu, May 9, 2019, at 4:06 PM, 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.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 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.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
> <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>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/a1ba85b3/attachment-0001.html>

From jacob at nerdonthestreet.com  Fri May 10 00:19:52 2019
From: jacob at nerdonthestreet.com (Jacob Kauffmann)
Date: Thu, 09 May 2019 19:19:52 -0400
Subject: =?UTF-8?Q?Re:_example_project:_19.04_Multitrack_compositing_still_broken?=
 =?UTF-8?Q?:_differs_from_all_previous_Kdenlive_versions_back_to_15_and_?=
 =?UTF-8?Q?before?=
In-Reply-To: <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
Message-ID: <f0cc69ac-5806-46ec-a180-d0ff42063082@www.fastmail.com>

> Could you describe specifically what is "slow" here? The preview? Moving clips around?

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 *after* the cut (the new clip *before* 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 *hundreds* 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.

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.)

> 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

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 *not* the one who started this chain!), you have to understand that my thought process isn't "oh, they changed how xyz code works, of *course* 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.

> As for the "few other issues", I invite you to submit them here https://invent.kde.org/kde/kdenlive/issues.

I'll be honest, I've been using KDE software for a long time, and I've never heard of invent.kde.org before. The "Bug reports" page on kdenlive.org (at https://kdenlive.org/en/bug-reports/) points to bugs.kde.org, which I monitor fairly regularly for Kdenlive and several other projects. Invent.kde.org looks much more modern (it looks like a GitLab deployment, I remember hearing something about that a while ago); is this a replacement for bugs.kde.org, or some kind of alternative/supplement? (It also has source code, so how does it relate to cgit.kde.org?)

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.

Thanks for your response!

- Jacob Kauffmann

On Thu, May 9, 2019, at 5:02 PM, alcinos wrote:
> 
> 
> Le jeu. 9 mai 2019 à 23:40, Jacob Kauffmann <jacob at nerdonthestreet.com> a écrit :
>> __
>> 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.
> 
> Thank you for your kind words. 
> 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"). 
> 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.
> 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.
> 
>> 
>> 
>> 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 *incredibly* 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.
> 
> Could you describe specifically what is "slow" here? The preview? Moving clips around?
> As for the "few other issues", I invite you to submit them here https://invent.kde.org/kde/kdenlive/issues. We can only fix issues if we are aware of them :)
> 
>> 
>> 
>> Older AppImages are still available for download right alongside the newest one, all the way back to 16.12.2: https://files.kde.org/kdenlive/release/ (Are the regressions worth the improvements? Decide for yourself and pick your poison.)
>> 
>> - Jacob Kauffmann
>> 
>> On Thu, May 9, 2019, at 4:06 PM, 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.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 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.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 <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>
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190509/5053615c/attachment-0001.html>

From french.ebook.lover at gmail.com  Fri May 10 01:04:10 2019
From: french.ebook.lover at gmail.com (alcinos)
Date: Fri, 10 May 2019 02:04:10 +0200
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <f0cc69ac-5806-46ec-a180-d0ff42063082@www.fastmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <f0cc69ac-5806-46ec-a180-d0ff42063082@www.fastmail.com>
Message-ID: <CAHJBWf=n0c-ZRxs4gXnZZSgZ2C6Rqjj8-EWYQEf12PXT-iBdLA@mail.gmail.com>

Le ven. 10 mai 2019 à 01:20, Jacob Kauffmann <jacob at nerdonthestreet.com> a
écrit :

> Could you describe specifically what is "slow" here? The preview? Moving
> clips around?
>
>
> 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 *after* the cut (the new clip *before* 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 *hundreds* 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.
>
> 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.)
>

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 (
https://invent.kde.org/kde/kdenlive/issues/181). 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).

>
> 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
>
>
> 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 *not* the one who started this chain!), you have to
> understand that my thought process isn't "oh, they changed how xyz code
> works, of *course* 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.
>

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.


>
> As for the "few other issues", I invite you to submit them here
> https://invent.kde.org/kde/kdenlive/issues.
>
>
> I'll be honest, I've been using KDE software for a long time, and I've
> never heard of invent.kde.org before. The "Bug reports" page on
> kdenlive.org (at https://kdenlive.org/en/bug-reports/) points to
> bugs.kde.org, which I monitor fairly regularly for Kdenlive and several
> other projects. Invent.kde.org looks much more modern (it looks like a
> GitLab deployment, I remember hearing something about that a while ago); is
> this a replacement for bugs.kde.org, or some kind of
> alternative/supplement? (It also has source code, so how does it relate to
> cgit.kde.org?)
>

Kdenlive has now fully moved to gitlab for the development. bugs.kde.org 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 bugs.kde.org (where if I'm not
mistaken it's easier to create an account). In practice, when a bug from
bugs.kde.org is confirmed, we usually open a mirror issue on the gitlab.
 As far as Kdenlive is concerned, cgit.kde.org is not used anymore, and
acts only as a mirror.


>
> 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.
>

If you are not reporting crashes, the debug symbols don't make any
difference, don't let that stop you :)
And even if you are, knowing that there is a crash somewhere is valuable.
Here are some general guidelines for good reports:

   - 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)
   - Make sure it doesn't happen in the latest version (the reference for
   it being the nightly appimage available here
   https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/
   )
   - Describe the steps to reproduce the bug (a video can be very helpful
   for this)
   - If applicable, it sometimes help to have a project file that triggers
   the bug (say if it doesn't occur from a blank project)

Every feedback is a gift, don't hesitate to report anything that bothers
you :)

Cheers!

>
> Thanks for your response!
>
> - Jacob Kauffmann
>
> On Thu, May 9, 2019, at 5:02 PM, alcinos wrote:
>
>
>
> Le jeu. 9 mai 2019 à 23:40, Jacob Kauffmann <jacob at nerdonthestreet.com> a
> écrit :
>
>
> 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.
>
>
> Thank you for your kind words.
> 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").
> 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.
> 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.
>
>
>
>
> 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
> *incredibly* 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.
>
>
> Could you describe specifically what is "slow" here? The preview? Moving
> clips around?
> As for the "few other issues", I invite you to submit them here
> https://invent.kde.org/kde/kdenlive/issues. We can only fix issues if we
> are aware of them :)
>
>
>
>
> Older AppImages are still available for download right alongside the
> newest one, all the way back to 16.12.2:
> https://files.kde.org/kdenlive/release/ (Are the regressions worth the
> improvements? Decide for yourself and pick your poison.)
>
> - Jacob Kauffmann
>
> On Thu, May 9, 2019, at 4:06 PM, 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.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 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.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
> <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>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/4c73f1cf/attachment-0001.html>

From evorster at gmail.com  Fri May 10 06:29:52 2019
From: evorster at gmail.com (Evert Vorster)
Date: Fri, 10 May 2019 07:29:52 +0200
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <CAHMxv37jNve=Zi+QAPrxF1HN06AmJx2ZDrONzf0prOf6J8Kg-A@mail.gmail.com>
References: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
 <CAHMxv37jNve=Zi+QAPrxF1HN06AmJx2ZDrONzf0prOf6J8Kg-A@mail.gmail.com>
Message-ID: <CAER78vRfxe-BQgyCbX_J5RrGqmPJihYtnFKJx3LH-8jM7VEcvQ@mail.gmail.com>

Hey there, Harald.

Harald, this last release is a massive one. As in, under the hood a LOT of
things have changed. As a package maintainer for the kdenlive package in
Arch I have been watching and tracking it for a while. (years) I was
wondering when the devs were going to be brave enough to bite the bullet
and call it stable. I commend them on their bravery, it's not an easy
thing.

The detail of your issue seems to be enough to have it resolved, but this
forum is not a bug tracker. Which brings me to a problem in the kdenlive
community.
Through the years I have seen a few different bug trackers, and we seem to
have the same problem with all of them. The bugs in them quickly multiply
to the point where the devs feel overwhelmed and the reporters feel under
appreciated. I myself have a few open bugs from 2016 that have not been
addressed and that I am not happy about. I have been told that they would
all be fixed with the new timeline code, which has just been released.

Now, my bugs are more of the OCD type, and since I am not a heavy user of
kdenlive anymore I will leave them alone while the devs hunt the bugs of
guys like you that use it daily.

My advice for you to keep your sanity... Use a previous version of Kdenlive
as your daily driver.
Occasionally check to see if the bugs that prevent you from using the
latest release has been fixed.

Peace
Evert Vorster
Awesome Chapters Tours
http://www.awesomechapters.com
Tel: +264 (0) 811477690


On Thu, 9 May 2019 at 21:01, farid abdelnour <snd.noise at gmail.com> wrote:

> 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.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
>> <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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bnfdgmkmphlpinlc.png
Type: image/png
Size: 33535 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kkhnlmafhidelmgh.png
Type: image/png
Size: 5538 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfpiknjpkigmkjpe.png
Type: image/png
Size: 5412 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgpabbbnjcnaofff.png
Type: image/png
Size: 45154 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdcehakombfedldb.png
Type: image/png
Size: 4381 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kojfbpgdjaoejjnb.png
Type: image/png
Size: 2321 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpadjfpjgpmiinma.png
Type: image/png
Size: 4460 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/127a94f2/attachment-0013.png>

From dougpol2 at gmail.com  Fri May 10 13:43:33 2019
From: dougpol2 at gmail.com (Douglas Pollard)
Date: Fri, 10 May 2019 08:43:33 -0400
Subject: Zoom and pan
Message-ID: <b62add6e-a648-f669-9c6d-78d3dc4205d5@Gmail.com>

I finished up a Video yesterday and searched for hours trying to find 
zoom and pan in Kdenlive 19.04.0 using Key frames.  I know it has to be 
there some place. I had to take my video  to Cinelerra to finish it. Can 
someone tell me were to find it. Seems to have disappeared??   Thanks Doug


From eugen.mohr at gmx.net  Fri May 10 14:59:00 2019
From: eugen.mohr at gmx.net (Eugen Mohr)
Date: Fri, 10 May 2019 15:59:00 +0200
Subject: Zoom and pan
In-Reply-To: <b62add6e-a648-f669-9c6d-78d3dc4205d5@Gmail.com>
References: <b62add6e-a648-f669-9c6d-78d3dc4205d5@Gmail.com>
Message-ID: <f76c1879-bc46-2df8-9376-18a188d54877@gmx.net>

Hi Doug

It’s unfortunately a bit hidden: Effects -> click on the “filmstrip”
icon and then you either search for zoom or you find it under
“Alpha/Transform”. In 19.04.1 the search function covers all effects.

Merlimau

Am 10.05.2019 um 14:43 schrieb Douglas Pollard:
> I finished up a Video yesterday and searched for hours trying to find
> zoom and pan in Kdenlive 19.04.0 using Key frames.  I know it has to
> be there some place. I had to take my video  to Cinelerra to finish
> it. Can someone tell me were to find it. Seems to have disappeared??  
> Thanks Doug
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/a6cd5d6e/attachment.html>

From snd.noise at gmail.com  Fri May 10 15:46:26 2019
From: snd.noise at gmail.com (farid abdelnour)
Date: Fri, 10 May 2019 11:46:26 -0300
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <CAER78vRfxe-BQgyCbX_J5RrGqmPJihYtnFKJx3LH-8jM7VEcvQ@mail.gmail.com>
References: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
 <CAHMxv37jNve=Zi+QAPrxF1HN06AmJx2ZDrONzf0prOf6J8Kg-A@mail.gmail.com>
 <CAER78vRfxe-BQgyCbX_J5RrGqmPJihYtnFKJx3LH-8jM7VEcvQ@mail.gmail.com>
Message-ID: <CAHMxv365kQgSUdJFT4WVio+d2O1pjtBkZatiThnU8S+67nveYw@mail.gmail.com>

Hi Evert

Em sex, 10 de mai de 2019 às 02:30, Evert Vorster <evorster at gmail.com>
escreveu:

> Hey there, Harald.
>
> Harald, this last release is a massive one. As in, under the hood a LOT of
> things have changed. As a package maintainer for the kdenlive package in
> Arch I have been watching and tracking it for a while. (years) I was
> wondering when the devs were going to be brave enough to bite the bullet
> and call it stable. I commend them on their bravery, it's not an easy thing.
>

Well technically it is still a WIP but much more stable than the old code
base. BAsically if we didn't release we would never find all these issues
by ourselves in a short ammount of time. Hence why we will dedicate the
whole 19.04 cycle for polishing.

>
> The detail of your issue seems to be enough to have it resolved, but this
> forum is not a bug tracker. Which brings me to a problem in the kdenlive
> community.
> Through the years I have seen a few different bug trackers, and we seem to
> have the same problem with all of them. The bugs in them quickly multiply
> to the point where the devs feel overwhelmed and the reporters feel under
> appreciated. I myself have a few open bugs from 2016 that have not been
> addressed and that I am not happy about. I have been told that they would
> all be fixed with the new timeline code, which has just been released.
>

That was the problem with the old code base, it was all duct-taped and
became unmaintainable. For one to add a feature it would break something
else... now we have a lean and clear code, bug fixes and new features are
easier and faster to do. Eugen has done an incredible work in maintaining
the bug tracker, closing duplicates, testing reports, etc... we have closed
more than a 100 reports since the end of last year. There is still a long
road ahead but we are getting there.

Now, my bugs are more of the OCD type, and since I am not a heavy user of
> kdenlive anymore I will leave them alone while the devs hunt the bugs of
> guys like you that use it daily.
>
> My advice for you to keep your sanity... Use a previous version of
> Kdenlive as your daily driver.
> Occasionally check to see if the bugs that prevent you from using the
> latest release has been fixed.
>

Great advice, we have kept a legacy link in the download page to the latest
18.12 series appimage. We hope to fix everything until the 19.08 release
and then the cool new features will start rolling.

Cheers

>
> Peace
> Evert Vorster
> Awesome Chapters Tours
> http://www.awesomechapters.com
> Tel: +264 (0) 811477690
>
>
> On Thu, 9 May 2019 at 21:01, farid abdelnour <snd.noise at gmail.com> wrote:
>
>> 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.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
>>> <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>
>>
>

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bnfdgmkmphlpinlc.png
Type: image/png
Size: 33535 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kkhnlmafhidelmgh.png
Type: image/png
Size: 5538 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lfpiknjpkigmkjpe.png
Type: image/png
Size: 5412 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgpabbbnjcnaofff.png
Type: image/png
Size: 45154 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdcehakombfedldb.png
Type: image/png
Size: 4381 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kojfbpgdjaoejjnb.png
Type: image/png
Size: 2321 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpadjfpjgpmiinma.png
Type: image/png
Size: 4460 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/5d950dfd/attachment-0013.png>

From stevebrodie at gmail.com  Fri May 10 17:07:45 2019
From: stevebrodie at gmail.com (Steve Brodie)
Date: Fri, 10 May 2019 17:07:45 +0100
Subject: Can't render
In-Reply-To: <72101e25-4052-ad92-fe9e-92776dd7f6b1@actiu.net>
References: <72101e25-4052-ad92-fe9e-92776dd7f6b1@actiu.net>
Message-ID: <ce3687c3-1f1e-487c-96ff-ccb5009b9e04@Spark>

I just wanted to say to Douglas that I’m really glad you got this resolved!
Don’t give up, we all need to keep trying to do and learn new things as we get a little bit older!
Hope you have a very happy 84th birthday in a few weeks!

Best wishes,

Steve
On 9 May 2019, 09:07 +0100, Narcis Garcia <informatica at actiu.net>, wrote:
> [reply to mailing list please]
>
>
> -------- Missatge reenviat --------
> Assumpte: Re: Fwd: Can't render
> Data: Wed, 8 May 2019 15:00:29 -0400
> De: Douglas Pollard <dougpol2 at gmail.com>
> A: Narcis Garcia <informatica at actiu.net>
>
> Well Narcis I just
>
> i found an invalid file among my video files I Deleted it and kdenlive
> is rendering. It's not finished yet but I think it will be OK.
> The questions you asked prompted me to go through again  everything
> including the video files I was using. Hadn't seen it before.
>  So problem solved. Thank you so much, Douglas Pollard  Got some
>  learning to do to catch up with the changes in Kdenlive but I like what
> I am seeing.
>
>
> On 5/8/19 12:44 PM, Narcis Garcia wrote:
> > -------- Missatge reenviat --------
> > Assumpte: Re: Can't render
> > Data: Wed, 8 May 2019 12:38:07 -0400
> > De: Douglas Pollard <dougpol2 at gmail.com>
> > A: Narcis Garcia <informatica at actiu.net>
> >
> > Also My computer is HP Elite Desktop with 16 gigs Memory
> >
> > Dual core    Doug
> >
> >
> > On 5/8/19 12:31 PM, Douglas Pollard wrote:
> > > I am using Mint 19.1 Tesa, 64 bit,   Kden Live 19.04.0, My video clips
> > > are from canon camera MP4 1080 Not sure where to find file size but
> > > the video is 17minutes long.  I will look for file size. Doug
> > >
> > >
> > > On 5/8/19 12:07 PM, Narcis Garcia wrote:
> > > > Please, provide:
> > > > - Operating system and version
> > > > - Kdenlive version and architecture
> > > > - Video clips format, length and file size
> > > >
> > > > El 8/5/19 a les 17:54, Douglas Pollard ha escrit:
> > > > > I have a Video of one video to timeline and one audio line. I had
> > > > > started to put pictures and video on a third time line Kdenlive
> > > > > crashed.  I went to Open recent to restart as my video did not come up
> > > > > on timeline or clips. I used a  tried a couple back up clips and they
> > > > > made video but still would not  render.   I used proxy-clips set to 500
> > > > > video and 500 audio. After five attempts to render I wound up with 4
> > > > > new
> > > > > recent titles all of them will play but will not render. In some
> > > > > moments
> > > > > of frustration I decided to give up on Kdenlive and deleted the program
> > > > > and after thinking about a few hours. I changed my mind  so downloaded
> > > > > Kdenlive again using Software  manager and flatpack. Installed my files
> > > > > again using couple backup files. Still will not render but sure like
> > > > > the
> > > > > new Kdenlive .   I have to add here that in a few weeks I will be 84
> > > > > years old and having doubts that I am still able to do video at all. I
> > > > > really hope that is not the case as I enjoy it and now have 82  videos
> > > > > on You tube. I have never j had a problem  Rendering before, so maybe I
> > > > > am about to learn a new trick? Sorry for writing a book. Thanks, Doug
> > > > >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190510/43ff0a7e/attachment.html>

From dan at progmeistars.lv  Sat May 11 14:56:24 2019
From: dan at progmeistars.lv (Daniil V. Kolpakov)
Date: Sat, 11 May 2019 16:56:24 +0300
Subject: example project: 19.04 Multitrack compositing still broken:
 differs from all previous Kdenlive versions back to 15 and before
In-Reply-To: <CAER78vRfxe-BQgyCbX_J5RrGqmPJihYtnFKJx3LH-8jM7VEcvQ@mail.gmail.com>
References: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
 <CAHMxv37jNve=Zi+QAPrxF1HN06AmJx2ZDrONzf0prOf6J8Kg-A@mail.gmail.com>
 <CAER78vRfxe-BQgyCbX_J5RrGqmPJihYtnFKJx3LH-8jM7VEcvQ@mail.gmail.com>
Message-ID: <c089cd61-ea04-f645-a0c8-9a9c429f7391@progmeistars.lv>

On 10.05.2019 08:29, Evert Vorster wrote:
> As a package maintainer for the kdenlive package in Arch

By the way, I'm an Arch user and I'm currently refraining from updating 
the Arch on my home machine because I have a long pre-19.04 project 
unfinished. I've also updated Arch at another machine at work and happen 
to edit another video with 19.04 — not my daily job but anyway. The 
19.04 looks more or less OK for me but I'm afraid of the project 
incompatibility. So I've downloaded an appimage (the 
kdenlive-18.12.1b-x86_64.appimage) and tried running it and opening my 
old project with it. Seems to work! Although I'm still afraid of 
updating the Arch :D

From unfa00 at gmail.com  Sat May 11 16:27:36 2019
From: unfa00 at gmail.com (=?UTF-8?Q?Tobiasz_Karo=C5=84?=)
Date: Sat, 11 May 2019 17:27:36 +0200
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
Message-ID: <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>

Hey!

I've read Harald's e-mail and I thought maybe I'll share my Kdenlvie
experience with you as well.

I've been a heavy Kdenlive user for about 18 months, when I switched from
Blender VSE, seeing it's not being worked on and I cannot expect the bugs
that cripple my workflow to be ever fixed.
About two months ago I've upgraded from 16 to 32 GB of RAM to help myself
with editing videos in Kdenlive.
A month later I immediately gave up using Kdeinlive, after I've discovered
Olive.

Olive is a very young project (about 20 months in development at this
point). And it made me realize how painful it is to do my work with
Kdenlive (or Blender VSE to be fair).
Olive uses OpenGL for all image processing. It uses GLSL shaders for
effects and compositing. I was even able to create a Despill effect myself
to get a better Green Screen compositing.

That being said I have a feeling that my trouble with Kdenlive will not
lead to any progress, and I prefer to have issues with Olive that has a
promising start and a community I can get in touch with easily.
Also - it gives me an order of magnitude better experience than anything
else right away, so why shouldn't iI use it?

A minro problem was for the past year (or something?) I couldn't log into
my KDE account, because they enforce using your real name as login, and I
have diacritics in my name, I also can't use a password that I'd want so I
had once to contact an admit to even log in, and I just don't have the tim
deal with that.. That made me feel like the KDE community is making it
harder for me to communicate.
Why can't I use a login and password of my choosing? I find that a strange
decision and I'm just out of the KDE forums until that's changed.

I've stopped reporting bugs, also knowing that the refactoring is a
priority.
I think Kdenlive has some great functions, but is also a huge mess.

There are three groups of effects based on keyframing (no keyframing, a
table keyframing, and a timeline keyframing). The effects are affecting the
image in ways they shouldn't - transform and wipe will change the color
balance, whic is visible on the RGB parade - I show that in my rant video).
The performance is abysmal if you want to do any compositing (which I do a
lot).
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.

There's a UV Mapping compositor, that's useless, because the whole pipeline
is only 8-bit. Which gives you 256x256 pixels addressable.

GPU support is non-functional and crashes Kdenlive every time for me.
Multithrraded rendering or even playback is broken and gives me white
frames every time.

My recent two serious projects got random audio sync issues and audio
clicks (randomly different with each render). That was the last straw for
me, and I snapped.

Here are the two last videos I've made with Kdenlive:
https://www.youtube.com/watch?v=YpMP8uGGpzI
https://www.youtube.com/watch?v=Ulks8T6z6BU

The issues created by Kdenlive in my work has cost me too much time and
beard hair. Even my wife is relived that I'm not using it any more.

I bless the Heavens for Olive, as I can retain my sanity and make videos
that I love.

I think that as long as Kdenlive is coupled with MLT - it'll be inhereting
it's problems.
I don't know how that looks on the inside, but I guess Kdenlive is probably
doing a lot of work just to workaround MLT's limitations and quirks.

Also - Kdenlvie has a long legacy, which is holding it back.
Olvie has non of that - and kowing it's developers and community - it migth
become a tool even better than some of the industry standards like Adobe
Premiere (which also has a lot of legacy and quirks).

Anyway - I've expressed my issues and frustration in a video:
https://youtu.be/ym1brc2OcYQ

After I published this, I one of the developers of Kdelvie cam to Olive
Disocrd and we got in touch talking about the issues.
I've send him my latest projects so he can investigate the audio
clicks/desync issue (I couldn't reproduce it in a simmle project).

I've decided to take that video down after a week. As I though maybe it's
sending a needlessly negative message, but since I've decidd to make it
public again, as there'struth there that has to be said, even if it's not
nice to listen to.
I hope you can undesrtand that.

I hope Kdenlive can be reborn, but I am afraid a lot of things just need to
be replaced entirely if it's going to ever become a truly modern video
editor.

In my honest opition (being completely unaware of the Kdenlive's internal
structure) it'd be better to just go back to the drawing board and design
an entirely new achitecture taking into account all experience of Kdenlive.
That experience is probably the most valuable asset you guys have.

I don't think you're gonna do that, as you've invested so much time and
effort into it. I'm thinking about the "sunken cost fallacy".
I'm a really sorry to say that - but I don't elbie any more that time spent
on improving Kdenlvie is a time well spent.
The end product is no good for me, and Olive is already allowing me to do
the same work faster, better and suicidal-thoughts free.

Some more facts from my experience of the past months comparing Kdenlive
and Olive:

Kdenlive is compositng in a single CPU thread (possibly in multiple if you
odn't use any effects - so let's ignore that), while my Ryzen 7 1700 CPU is
at 10% load, and my Nvidia GTX 1060 GPU is completely idle.
When I render vidoes with Olive, my CPU is at 60-70% with all threads
active, and my GPU is at 30-40% load.

When I work with Olive - I can finally see in realtime what I'm doing, with
proper compositing, even without using Proxy.
In Kdenlive if I use 2-3 layers at a time and a few transporm effects I'm
down to 3 FPS and I'm guessing what the video will look like. And I use
proxy in Kdenlive or it's down to 1FPS.

Olive (in alpha stage) has solid crash recovery (I never lost any work from
a crash yet) and crashes about 5-8 times less than Kdenlive 18 on my system.
I've been begging for crash recover in Kdenlive to be implemented, and I
had to give up my parallel rendering script when it was added, because that
broke.

Yes, I've coded an external tool to help me render Kdenlive projects
faster. but a new version of Kdnelive changed something and I couldn't get
it to work evr again.
Still - loosing 30 minutes of work is worse than rendering a video all
night, so I've picked my poison.

I hoped that maybe this will be implemented in Kdenlive itself at some
point:
https://github.com/unfa/kdenlive-multirender

Now I don't need to hack together stuff like that because Olive just
utilizes my hardware. It renders my projects in near-realitime.

I have nothing but love for you guys. The frustration is only for the
issues I experienced and how they made my work needlessly painful.
Experience working on my last Kdenlvie video made me consider using some
proprietary software - for the first time in my life.
That's how bad that experience was. And I know I've checked all the other
open-source NLAs too already. They are all like this. Stuck in the 90s.
Only Olive isn't.

I also felt I need to share my perspective publicly (in that rant video),
because many people regard Kdenlive as "open-source state of the art NLA"
and that's just not true and (in my opinion) very harmful to the image of
what the open-source commnity can create.

I saw The Linux Gamer and Wendell benchmark Kdenlive once on some insane
hardware with multiple GPUs and I was grinding my teeth - because Kdenlive
can't use that hardware at all and there's no point even having a GPU for
Kdenlive.

Please forgive me if I have hurt you with this e-mail. That was not my
intention.
I wanted to share this, becasue I hope you can benefit from my story.

I wish you all the best,
- unfa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190511/ca443135/attachment.html>

From jacob at nerdonthestreet.com  Sat May 11 18:50:13 2019
From: jacob at nerdonthestreet.com (Jacob Kauffmann)
Date: Sat, 11 May 2019 13:50:13 -0400
Subject: =?UTF-8?Q?Re:_example_project:_19.04_Multitrack_compositing_still_broken?=
 =?UTF-8?Q?:_differs_from_all_previous_Kdenlive_versions_back_to_15_and_?=
 =?UTF-8?Q?before?=
In-Reply-To: <c089cd61-ea04-f645-a0c8-9a9c429f7391@progmeistars.lv>
References: <9e692325-5089-cce6-74ad-b4d70a3d27b5@gmx.net>
 <CAHMxv37jNve=Zi+QAPrxF1HN06AmJx2ZDrONzf0prOf6J8Kg-A@mail.gmail.com>
 <CAER78vRfxe-BQgyCbX_J5RrGqmPJihYtnFKJx3LH-8jM7VEcvQ@mail.gmail.com>
 <c089cd61-ea04-f645-a0c8-9a9c429f7391@progmeistars.lv>
Message-ID: <5a0d5038-cf5c-4861-be28-bf89ef2214b6@www.fastmail.com>


On Sat, May 11, 2019, at 8:55 AM, Daniil V. Kolpakov wrote:
> So I've downloaded an appimage (the 
> kdenlive-18.12.1b-x86_64.appimage) and tried running it and opening my 
> old project with it. Seems to work! Although I'm still afraid of 
> updating the Arch :D
>

If the AppImage can open your project, there's nothing dangerous about updating the package. AppImages are completely self-contained and don't rely on the packages.

From jacob at nerdonthestreet.com  Sat May 11 19:02:54 2019
From: jacob at nerdonthestreet.com (Jacob Kauffmann)
Date: Sat, 11 May 2019 14:02:54 -0400
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
Message-ID: <a8c79bd1-e213-47df-a83e-6188ad1a68bd@www.fastmail.com>


On Sat, May 11, 2019, at 10:28 AM, Tobiasz Karoń wrote:
> 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.

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."

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.)

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.

Just my two cents, since it seems like it's sharing day.

- Jacob Kauffmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190511/1caaabde/attachment-0001.html>

From unfa00 at gmail.com  Sat May 11 20:15:02 2019
From: unfa00 at gmail.com (=?UTF-8?Q?Tobiasz_Karo=C5=84?=)
Date: Sat, 11 May 2019 21:15:02 +0200
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <a8c79bd1-e213-47df-a83e-6188ad1a68bd@www.fastmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
 <a8c79bd1-e213-47df-a83e-6188ad1a68bd@www.fastmail.com>
Message-ID: <CAOsCCbNusfJvv7suo0khT4GrD=c_g2r7paMxEABFscjQ7p4cTg@mail.gmail.com>

sob., 11 maj 2019 o 20:03 Jacob Kauffmann <jacob at nerdonthestreet.com>
napisał(a):

>
> On Sat, May 11, 2019, at 10:28 AM, Tobiasz Karoń wrote:
>
> 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.
>
>
> 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."
>
Oh no - that's not what I meant. I am pretty serious about making videos,
and I know many people who also use Kdenlive for serious work
What I wanted to say is that doing complex work in Kdenlive is an order of
magnitude harder than doing very simple ones. The software becomes very
flaky, and the user needs to take extra caution and wokraround problems as
their projects complexity grows. That's my experience at least.

For example - I had so much problems with the Rotoscoping effect that I
just decided to stop trying, becasue it gave me more trouble than gains.
Maybe for some users (on some systems?) they can work reliably,
unfortunately not for me :)


> 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.)
>
I had the same "revelation" once I tried Olive. I was like "Wo my hardware
CAN process it this fast? WOW!"


> 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.
>
If that's the case, then I'm looking forward to it.


> Just my two cents, since it seems like it's sharing day.
>
> - Jacob Kauffmann
>

Thanks!

-- 
- Tobiasz 'unfa' Karoń

www.youtube.com/unfa000
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190511/01dace83/attachment.html>

From tv.lists at gmail.com  Sun May 12 09:00:21 2019
From: tv.lists at gmail.com (Mettavihari D)
Date: Sun, 12 May 2019 09:00:21 +0100
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <a8c79bd1-e213-47df-a83e-6188ad1a68bd@www.fastmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
 <a8c79bd1-e213-47df-a83e-6188ad1a68bd@www.fastmail.com>
Message-ID: <CAMRsyOduAC9anz=ung=4CPx1t5Q+L66hYfTo9Qk4WDgtzLJPkQ@mail.gmail.com>

Greetings from Sri Lanka

We are clear Open Source Users, started with Cinelerra some years ago,
after that switched to Kdenlive with blender to support in the graphics.
I still like the basic cinerella.

Sure we will also try Olive, but at present we have close to 50 PCs running
Ubuntu and Kdenlive.

So thanks to all of you for staying alive.
We do not talk much on the list, but at least you know that you have
users,  who are happy that you exist.

Mettavihari

On Sat, 11 May 2019, 19:03 Jacob Kauffmann, <jacob at nerdonthestreet.com>
wrote:

>
> On Sat, May 11, 2019, at 10:28 AM, Tobiasz Karoń wrote:
>
> 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.
>
>
> 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."
>
> 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.)
>
> 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.
>
> Just my two cents, since it seems like it's sharing day.
>
> - Jacob Kauffmann
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190512/fe1cac28/attachment.html>

From andres.tello at gmail.com  Sun May 12 18:01:07 2019
From: andres.tello at gmail.com (andres tello)
Date: Sun, 12 May 2019 12:01:07 -0500
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <CAMRsyOduAC9anz=ung=4CPx1t5Q+L66hYfTo9Qk4WDgtzLJPkQ@mail.gmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
 <a8c79bd1-e213-47df-a83e-6188ad1a68bd@www.fastmail.com>
 <CAMRsyOduAC9anz=ung=4CPx1t5Q+L66hYfTo9Qk4WDgtzLJPkQ@mail.gmail.com>
Message-ID: <CAArVfJeMf5axL6vvJEBRLGofEVBQ-ONQKhFH5CV3Z8pTAZAMCw@mail.gmail.com>

I never was able to run cinelerra... it crashed tooo badly...  I'm a
professional linux and service provider since 2004, and I know no to
migrate to my workflow to the newer versions until fully tested....

That is how Open Source works, and every time there is a big change, like
newest version from KDEnlive, a lot of work is needed to get to the
stability of the previous I remeber when linux changed to glibc, what a
nightmare, migration from lilo to grub? awful... the introduction of LVM?
just dont' start when kdelibs changed their licence model to GPL.... O my
good what a soup opera is Linux...

This instability is needed, but will always achieve better results....

Don't give up on kdenlive, just return to your working version, that is the
idea of appimages, allow us go back and forth version with out compromising
our source of income...
That is how professionals work...




On Sun, May 12, 2019 at 3:00 AM Mettavihari D <tv.lists at gmail.com> wrote:

> Greetings from Sri Lanka
>
> We are clear Open Source Users, started with Cinelerra some years ago,
> after that switched to Kdenlive with blender to support in the graphics.
> I still like the basic cinerella.
>
> Sure we will also try Olive, but at present we have close to 50 PCs
> running Ubuntu and Kdenlive.
>
> So thanks to all of you for staying alive.
> We do not talk much on the list, but at least you know that you have
> users,  who are happy that you exist.
>
> Mettavihari
>
> On Sat, 11 May 2019, 19:03 Jacob Kauffmann, <jacob at nerdonthestreet.com>
> wrote:
>
>>
>> On Sat, May 11, 2019, at 10:28 AM, Tobiasz Karoń wrote:
>>
>> 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.
>>
>>
>> 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."
>>
>> 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.)
>>
>> 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.
>>
>> Just my two cents, since it seems like it's sharing day.
>>
>> - Jacob Kauffmann
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190512/9f1d684c/attachment.html>

From ftechene at yahoo.fr  Sun May 12 18:44:42 2019
From: ftechene at yahoo.fr (=?UTF-8?B?RnJhbsOnb2lzIFTDqWNoZW7DqQ==?=)
Date: Sun, 12 May 2019 19:44:42 +0200
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
Message-ID: <3e748bb2-3c96-3f5b-dd27-375b753a373c@yahoo.fr>

Hi,

I take this opportunity to give you my personal feedback about Kdenlive
vs Olive as I have been using Kdenlive professionally for the last 3
years and I have also tried Olive recently.

I have also been pretty much impressed by Olive, especially the GPU
features that make a smooth experience with almost every filter and
every transition. I believe that Olive is pretty promising, and I am
watching its evolution closely, but it is still not matching my
requirements in term of stability and features, especially in term of
color grading.

Kdenive, however, has been improving so much in the past 3 years and is
now pretty close to match all my requirements.

It is not using GPU rendering but its proxy and preview features are so
convenient that it makes any processing intensive editing never be an
issue. It has almost no limit in that regard, not even the limit of my
GPU capacities.

I would also add that scrubbing is always very smooth for me on
Kdenlive, while it is not yet on Olive (this is a must have for me).

Also, the color grading in Kdenlive is a real pleasure. I do an intense
use of blending modes as well as a few filters like saturation and
levels. I also use the Waveforme and Vectorscope graphs that work
perfectly on Kdenlive.

One thing that was really missing in Kdenlive is the ability to port my
timeline to Ardour, but I have done a python script to achieve that, as
part of my latest project, and I am going to share that as free software.

Here is my latest work (I am making a behind the scene video to show my
workflow) :

https://www.youtube.com/watch?v=V0a03NRpX3Y

I have mainly used Kdenlive for that video. It seems pretty simple
because there is no visual effects nor crazy transitions but believe me
the work I have done on the color is pretty advanced and process intensive.

So my conclusion is that while Olive is very promising, Kdenlive remains
a lot more suited to my professional workflow.

Cheers,

François


On 11/05/2019 17:27, Tobiasz Karoń wrote:
> Hey!
> 
> I've read Harald's e-mail and I thought maybe I'll share my Kdenlvie
> experience with you as well.
> 
> I've been a heavy Kdenlive user for about 18 months, when I switched
> from Blender VSE, seeing it's not being worked on and I cannot expect
> the bugs that cripple my workflow to be ever fixed.
> About two months ago I've upgraded from 16 to 32 GB of RAM to help
> myself with editing videos in Kdenlive.
> A month later I immediately gave up using Kdeinlive, after I've
> discovered Olive.
> 
> Olive is a very young project (about 20 months in development at this
> point). And it made me realize how painful it is to do my work with
> Kdenlive (or Blender VSE to be fair).
> Olive uses OpenGL for all image processing. It uses GLSL shaders for
> effects and compositing. I was even able to create a Despill effect
> myself to get a better Green Screen compositing.
> 
> That being said I have a feeling that my trouble with Kdenlive will not
> lead to any progress, and I prefer to have issues with Olive that has a
> promising start and a community I can get in touch with easily.
> Also - it gives me an order of magnitude better experience than anything
> else right away, so why shouldn't iI use it?
> 
> A minro problem was for the past year (or something?) I couldn't log
> into my KDE account, because they enforce using your real name as login,
> and I have diacritics in my name, I also can't use a password that I'd
> want so I had once to contact an admit to even log in, and I just don't
> have the tim deal with that.. That made me feel like the KDE community
> is making it harder for me to communicate.
> Why can't I use a login and password of my choosing? I find that a
> strange decision and I'm just out of the KDE forums until that's changed.
> 
> I've stopped reporting bugs, also knowing that the refactoring is a
> priority.
> I think Kdenlive has some great functions, but is also a huge mess.
> 
> There are three groups of effects based on keyframing (no keyframing, a
> table keyframing, and a timeline keyframing). The effects are affecting
> the image in ways they shouldn't - transform and wipe will change the
> color balance, whic is visible on the RGB parade - I show that in my
> rant video). The performance is abysmal if you want to do any
> compositing (which I do a lot).
> 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.
> 
> There's a UV Mapping compositor, that's useless, because the whole
> pipeline is only 8-bit. Which gives you 256x256 pixels addressable. 
> 
> GPU support is non-functional and crashes Kdenlive every time for me.
> Multithrraded rendering or even playback is broken and gives me white
> frames every time.
> 
> My recent two serious projects got random audio sync issues and audio
> clicks (randomly different with each render). That was the last straw
> for me, and I snapped.
> 
> Here are the two last videos I've made with Kdenlive:
> https://www.youtube.com/watch?v=YpMP8uGGpzI
> https://www.youtube.com/watch?v=Ulks8T6z6BU
> 
> The issues created by Kdenlive in my work has cost me too much time and
> beard hair. Even my wife is relived that I'm not using it any more.
> 
> I bless the Heavens for Olive, as I can retain my sanity and make videos
> that I love.
> 
> I think that as long as Kdenlive is coupled with MLT - it'll be
> inhereting it's problems.
> I don't know how that looks on the inside, but I guess Kdenlive is
> probably doing a lot of work just to workaround MLT's limitations and
> quirks.
> 
> Also - Kdenlvie has a long legacy, which is holding it back.
> Olvie has non of that - and kowing it's developers and community - it
> migth become a tool even better than some of the industry standards like
> Adobe Premiere (which also has a lot of legacy and quirks).
> 
> Anyway - I've expressed my issues and frustration in a video:
> https://youtu.be/ym1brc2OcYQ
> 
> After I published this, I one of the developers of Kdelvie cam to Olive
> Disocrd and we got in touch talking about the issues.
> I've send him my latest projects so he can investigate the audio
> clicks/desync issue (I couldn't reproduce it in a simmle project).
> 
> I've decided to take that video down after a week. As I though maybe
> it's sending a needlessly negative message, but since I've decidd to
> make it public again, as there'struth there that has to be said, even if
> it's not nice to listen to.
> I hope you can undesrtand that.
> 
> I hope Kdenlive can be reborn, but I am afraid a lot of things just need
> to be replaced entirely if it's going to ever become a truly modern
> video editor.
> 
> In my honest opition (being completely unaware of the Kdenlive's
> internal structure) it'd be better to just go back to the drawing board
> and design an entirely new achitecture taking into account all
> experience of Kdenlive.
> That experience is probably the most valuable asset you guys have.
> 
> I don't think you're gonna do that, as you've invested so much time and
> effort into it. I'm thinking about the "sunken cost fallacy".
> I'm a really sorry to say that - but I don't elbie any more that time
> spent on improving Kdenlvie is a time well spent.
> The end product is no good for me, and Olive is already allowing me to
> do the same work faster, better and suicidal-thoughts free.
> 
> Some more facts from my experience of the past months comparing Kdenlive
> and Olive:
> 
> Kdenlive is compositng in a single CPU thread (possibly in multiple if
> you odn't use any effects - so let's ignore that), while my Ryzen 7 1700
> CPU is at 10% load, and my Nvidia GTX 1060 GPU is completely idle.
> When I render vidoes with Olive, my CPU is at 60-70% with all threads
> active, and my GPU is at 30-40% load.
> 
> When I work with Olive - I can finally see in realtime what I'm doing,
> with proper compositing, even without using Proxy.
> In Kdenlive if I use 2-3 layers at a time and a few transporm effects
> I'm down to 3 FPS and I'm guessing what the video will look like. And I
> use proxy in Kdenlive or it's down to 1FPS.
> 
> Olive (in alpha stage) has solid crash recovery (I never lost any work
> from a crash yet) and crashes about 5-8 times less than Kdenlive 18 on
> my system.
> I've been begging for crash recover in Kdenlive to be implemented, and I
> had to give up my parallel rendering script when it was added, because
> that broke. 
> 
> Yes, I've coded an external tool to help me render Kdenlive projects
> faster. but a new version of Kdnelive changed something and I couldn't
> get it to work evr again.
> Still - loosing 30 minutes of work is worse than rendering a video all
> night, so I've picked my poison.
> 
> I hoped that maybe this will be implemented in Kdenlive itself at some
> point:
> https://github.com/unfa/kdenlive-multirender
> 
> Now I don't need to hack together stuff like that because Olive just
> utilizes my hardware. It renders my projects in near-realitime.
> 
> I have nothing but love for you guys. The frustration is only for the
> issues I experienced and how they made my work needlessly painful.
> Experience working on my last Kdenlvie video made me consider using some
> proprietary software - for the first time in my life.
> That's how bad that experience was. And I know I've checked all the
> other open-source NLAs too already. They are all like this. Stuck in the
> 90s.
> Only Olive isn't.
> 
> I also felt I need to share my perspective publicly (in that rant
> video), because many people regard Kdenlive as "open-source state of the
> art NLA" and that's just not true and (in my opinion) very harmful to
> the image of what the open-source commnity can create.
> 
> I saw The Linux Gamer and Wendell benchmark Kdenlive once on some insane
> hardware with multiple GPUs and I was grinding my teeth - because
> Kdenlive can't use that hardware at all and there's no point even having
> a GPU for Kdenlive.
> 
> Please forgive me if I have hurt you with this e-mail. That was not my
> intention.
> I wanted to share this, becasue I hope you can benefit from my story.
> 
> I wish you all the best,
> - unfa

From lv at loicvanderstichelen.com  Mon May 13 12:45:20 2019
From: lv at loicvanderstichelen.com (lv at loicvanderstichelen.com)
Date: Mon, 13 May 2019 13:45:20 +0200
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <3e748bb2-3c96-3f5b-dd27-375b753a373c@yahoo.fr>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
 <3e748bb2-3c96-3f5b-dd27-375b753a373c@yahoo.fr>
Message-ID: <69dfd6de06a2751a696bc1aa2671bbd6@loicvanderstichelen.com>

Hi everybody,

There is a plenty of ways to use an NLE. It depends what your purpose.

If you are a Youtuber, a documentary editor, a fiction editor or a news 
editor it's not
exactlly the same mathod of editing.

I the company I'm working (so in the proprietary world), they use Edius 
for news and they use Premiere for promo clips, social networks.
My friends who are making documentary films or fiction use Avid (they 
come from INSAS cinema school in Brussels).
Some of them are testing Da Vinci Resolve but they are thinking that is 
not ready yet.

Why Edius for news ? It's very fast. Effects are terrible but it's 
really really fast. Perfect when you need to deliver something quickly.
Why Premiere for clips ? Because Adobe has a lot of experience in 
typography and in graphics.
You can deliver quickly something graphically convincing in the Adobe 
environment.
Why Avid for filmmakers ? It has been thought by filmmakers.

The question is what kind of editing style Kdenlive is mainly focusing ?

As filmmaker (and teacher) Olive is more performant in effects but it is 
not as good as Kdenlive to organize a project (no comments in the 
project bin, no decklink support).
Olive has the possibility to imbricate multiple timelines.
I hope refactory will bring that function very soon to Kdenlive because 
it's absolutly essential when you edit documentary or fiction film.
Effects are not important to me as long as it is possible to export on a 
compositer like Blender (or Natron if it still exists ?).
Same for audio : it's mush more confortable to mix on a specific 
application (Ardour ?)

François, do you share a link to your python script ?

Cheers,

Loïc











Le 2019-05-12 19:44, François Téchené a écrit :
> Hi,
> 
> I take this opportunity to give you my personal feedback about Kdenlive
> vs Olive as I have been using Kdenlive professionally for the last 3
> years and I have also tried Olive recently.
> 
> I have also been pretty much impressed by Olive, especially the GPU
> features that make a smooth experience with almost every filter and
> every transition. I believe that Olive is pretty promising, and I am
> watching its evolution closely, but it is still not matching my
> requirements in term of stability and features, especially in term of
> color grading.
> 
> Kdenive, however, has been improving so much in the past 3 years and is
> now pretty close to match all my requirements.
> 
> It is not using GPU rendering but its proxy and preview features are so
> convenient that it makes any processing intensive editing never be an
> issue. It has almost no limit in that regard, not even the limit of my
> GPU capacities.
> 
> I would also add that scrubbing is always very smooth for me on
> Kdenlive, while it is not yet on Olive (this is a must have for me).
> 
> Also, the color grading in Kdenlive is a real pleasure. I do an intense
> use of blending modes as well as a few filters like saturation and
> levels. I also use the Waveforme and Vectorscope graphs that work
> perfectly on Kdenlive.
> 
> One thing that was really missing in Kdenlive is the ability to port my
> timeline to Ardour, but I have done a python script to achieve that, as
> part of my latest project, and I am going to share that as free 
> software.
> 
> Here is my latest work (I am making a behind the scene video to show my
> workflow) :
> 
> https://www.youtube.com/watch?v=V0a03NRpX3Y
> 
> I have mainly used Kdenlive for that video. It seems pretty simple
> because there is no visual effects nor crazy transitions but believe me
> the work I have done on the color is pretty advanced and process 
> intensive.
> 
> So my conclusion is that while Olive is very promising, Kdenlive 
> remains
> a lot more suited to my professional workflow.
> 
> Cheers,
> 
> François
> 
> 
> On 11/05/2019 17:27, Tobiasz Karoń wrote:
>> Hey!
>> 
>> I've read Harald's e-mail and I thought maybe I'll share my Kdenlvie
>> experience with you as well.
>> 
>> I've been a heavy Kdenlive user for about 18 months, when I switched
>> from Blender VSE, seeing it's not being worked on and I cannot expect
>> the bugs that cripple my workflow to be ever fixed.
>> About two months ago I've upgraded from 16 to 32 GB of RAM to help
>> myself with editing videos in Kdenlive.
>> A month later I immediately gave up using Kdeinlive, after I've
>> discovered Olive.
>> 
>> Olive is a very young project (about 20 months in development at this
>> point). And it made me realize how painful it is to do my work with
>> Kdenlive (or Blender VSE to be fair).
>> Olive uses OpenGL for all image processing. It uses GLSL shaders for
>> effects and compositing. I was even able to create a Despill effect
>> myself to get a better Green Screen compositing.
>> 
>> That being said I have a feeling that my trouble with Kdenlive will 
>> not
>> lead to any progress, and I prefer to have issues with Olive that has 
>> a
>> promising start and a community I can get in touch with easily.
>> Also - it gives me an order of magnitude better experience than 
>> anything
>> else right away, so why shouldn't iI use it?
>> 
>> A minro problem was for the past year (or something?) I couldn't log
>> into my KDE account, because they enforce using your real name as 
>> login,
>> and I have diacritics in my name, I also can't use a password that I'd
>> want so I had once to contact an admit to even log in, and I just 
>> don't
>> have the tim deal with that.. That made me feel like the KDE community
>> is making it harder for me to communicate.
>> Why can't I use a login and password of my choosing? I find that a
>> strange decision and I'm just out of the KDE forums until that's 
>> changed.
>> 
>> I've stopped reporting bugs, also knowing that the refactoring is a
>> priority.
>> I think Kdenlive has some great functions, but is also a huge mess.
>> 
>> There are three groups of effects based on keyframing (no keyframing, 
>> a
>> table keyframing, and a timeline keyframing). The effects are 
>> affecting
>> the image in ways they shouldn't - transform and wipe will change the
>> color balance, whic is visible on the RGB parade - I show that in my
>> rant video). The performance is abysmal if you want to do any
>> compositing (which I do a lot).
>> 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.
>> 
>> There's a UV Mapping compositor, that's useless, because the whole
>> pipeline is only 8-bit. Which gives you 256x256 pixels addressable. 
>> 
>> GPU support is non-functional and crashes Kdenlive every time for me.
>> Multithrraded rendering or even playback is broken and gives me white
>> frames every time.
>> 
>> My recent two serious projects got random audio sync issues and audio
>> clicks (randomly different with each render). That was the last straw
>> for me, and I snapped.
>> 
>> Here are the two last videos I've made with Kdenlive:
>> https://www.youtube.com/watch?v=YpMP8uGGpzI
>> https://www.youtube.com/watch?v=Ulks8T6z6BU
>> 
>> The issues created by Kdenlive in my work has cost me too much time 
>> and
>> beard hair. Even my wife is relived that I'm not using it any more.
>> 
>> I bless the Heavens for Olive, as I can retain my sanity and make 
>> videos
>> that I love.
>> 
>> I think that as long as Kdenlive is coupled with MLT - it'll be
>> inhereting it's problems.
>> I don't know how that looks on the inside, but I guess Kdenlive is
>> probably doing a lot of work just to workaround MLT's limitations and
>> quirks.
>> 
>> Also - Kdenlvie has a long legacy, which is holding it back.
>> Olvie has non of that - and kowing it's developers and community - it
>> migth become a tool even better than some of the industry standards 
>> like
>> Adobe Premiere (which also has a lot of legacy and quirks).
>> 
>> Anyway - I've expressed my issues and frustration in a video:
>> https://youtu.be/ym1brc2OcYQ
>> 
>> After I published this, I one of the developers of Kdelvie cam to 
>> Olive
>> Disocrd and we got in touch talking about the issues.
>> I've send him my latest projects so he can investigate the audio
>> clicks/desync issue (I couldn't reproduce it in a simmle project).
>> 
>> I've decided to take that video down after a week. As I though maybe
>> it's sending a needlessly negative message, but since I've decidd to
>> make it public again, as there'struth there that has to be said, even 
>> if
>> it's not nice to listen to.
>> I hope you can undesrtand that.
>> 
>> I hope Kdenlive can be reborn, but I am afraid a lot of things just 
>> need
>> to be replaced entirely if it's going to ever become a truly modern
>> video editor.
>> 
>> In my honest opition (being completely unaware of the Kdenlive's
>> internal structure) it'd be better to just go back to the drawing 
>> board
>> and design an entirely new achitecture taking into account all
>> experience of Kdenlive.
>> That experience is probably the most valuable asset you guys have.
>> 
>> I don't think you're gonna do that, as you've invested so much time 
>> and
>> effort into it. I'm thinking about the "sunken cost fallacy".
>> I'm a really sorry to say that - but I don't elbie any more that time
>> spent on improving Kdenlvie is a time well spent.
>> The end product is no good for me, and Olive is already allowing me to
>> do the same work faster, better and suicidal-thoughts free.
>> 
>> Some more facts from my experience of the past months comparing 
>> Kdenlive
>> and Olive:
>> 
>> Kdenlive is compositng in a single CPU thread (possibly in multiple if
>> you odn't use any effects - so let's ignore that), while my Ryzen 7 
>> 1700
>> CPU is at 10% load, and my Nvidia GTX 1060 GPU is completely idle.
>> When I render vidoes with Olive, my CPU is at 60-70% with all threads
>> active, and my GPU is at 30-40% load.
>> 
>> When I work with Olive - I can finally see in realtime what I'm doing,
>> with proper compositing, even without using Proxy.
>> In Kdenlive if I use 2-3 layers at a time and a few transporm effects
>> I'm down to 3 FPS and I'm guessing what the video will look like. And 
>> I
>> use proxy in Kdenlive or it's down to 1FPS.
>> 
>> Olive (in alpha stage) has solid crash recovery (I never lost any work
>> from a crash yet) and crashes about 5-8 times less than Kdenlive 18 on
>> my system.
>> I've been begging for crash recover in Kdenlive to be implemented, and 
>> I
>> had to give up my parallel rendering script when it was added, because
>> that broke. 
>> 
>> Yes, I've coded an external tool to help me render Kdenlive projects
>> faster. but a new version of Kdnelive changed something and I couldn't
>> get it to work evr again.
>> Still - loosing 30 minutes of work is worse than rendering a video all
>> night, so I've picked my poison.
>> 
>> I hoped that maybe this will be implemented in Kdenlive itself at some
>> point:
>> https://github.com/unfa/kdenlive-multirender
>> 
>> Now I don't need to hack together stuff like that because Olive just
>> utilizes my hardware. It renders my projects in near-realitime.
>> 
>> I have nothing but love for you guys. The frustration is only for the
>> issues I experienced and how they made my work needlessly painful.
>> Experience working on my last Kdenlvie video made me consider using 
>> some
>> proprietary software - for the first time in my life.
>> That's how bad that experience was. And I know I've checked all the
>> other open-source NLAs too already. They are all like this. Stuck in 
>> the
>> 90s.
>> Only Olive isn't.
>> 
>> I also felt I need to share my perspective publicly (in that rant
>> video), because many people regard Kdenlive as "open-source state of 
>> the
>> art NLA" and that's just not true and (in my opinion) very harmful to
>> the image of what the open-source commnity can create.
>> 
>> I saw The Linux Gamer and Wendell benchmark Kdenlive once on some 
>> insane
>> hardware with multiple GPUs and I was grinding my teeth - because
>> Kdenlive can't use that hardware at all and there's no point even 
>> having
>> a GPU for Kdenlive.
>> 
>> Please forgive me if I have hurt you with this e-mail. That was not my
>> intention.
>> I wanted to share this, becasue I hope you can benefit from my story.
>> 
>> I wish you all the best,
>> - unfa

From ftechene at yahoo.fr  Mon May 13 14:37:54 2019
From: ftechene at yahoo.fr (=?UTF-8?B?RnJhbsOnb2lzIFTDqWNoZW7DqQ==?=)
Date: Mon, 13 May 2019 15:37:54 +0200
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <69dfd6de06a2751a696bc1aa2671bbd6@loicvanderstichelen.com>
References: <0LgMCe-1gsot70h8O-00nhRq@mail.gmx.com>
 <beeaa9cb-57f2-481c-beac-52a8ffd8f093@www.fastmail.com>
 <CAHJBWf==n8Da=Kafx9+uTPKVL43pvsTuxy8y-BUNMmzijBSipg@mail.gmail.com>
 <CAOsCCbOfPr7u4E1x6HWT1qLh9jXhSp5UVDhw7tmHqO4eYvYu_g@mail.gmail.com>
 <3e748bb2-3c96-3f5b-dd27-375b753a373c@yahoo.fr>
 <69dfd6de06a2751a696bc1aa2671bbd6@loicvanderstichelen.com>
Message-ID: <1bc74b0a-af59-2c4d-4853-a3873dcad460@yahoo.fr>

Hi Loïc,

On 13/05/2019 13:45, lv at loicvanderstichelen.com wrote:
> 
> François, do you share a link to your python script ?
> 

Sure! I need to add it to a proper git public repository, along with the
right license and I will share it with everyone.

Cheers,

François

From informatica at actiu.net  Wed May 15 17:54:11 2019
From: informatica at actiu.net (Narcis Garcia)
Date: Wed, 15 May 2019 18:54:11 +0200
Subject: A story of a former Kdenlive's user (switched to Olive)
In-Reply-To: <CAOsCCbNusfJvv7suo0khT4GrD=c_g2r7paMxEABFscjQ7p4cTg@mail.gmail.com>
Message-ID: <0e8ae01e-8250-62d4-76d4-ffc127780023@actiu.net>

El 11/5/19 a les 21:15, Tobiasz Karoń ha escrit:
> 
> 
> sob., 11 maj 2019 o 20:03 Jacob Kauffmann <jacob at nerdonthestreet.com
 <mailto:jacob at nerdonthestreet.com>> napisał(a):
> 
>     __
> 
>     On Sat, May 11, 2019, at 10:28 AM, Tobiasz Karoń wrote:
>>     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.
> 
>     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."
> 
> Oh no - that's not what I meant. I am pretty serious about making
> videos, and I know many people who also use Kdenlive for serious work
> What I wanted to say is that doing complex work in Kdenlive is an order
> of magnitude harder than doing very simple ones. The software becomes
> very flaky, and the user needs to take extra caution and wokraround
> problems as their projects complexity grows. That's my experience at least.
> 
> For example - I had so much problems with the Rotoscoping effect that I
> just decided to stop trying, becasue it gave me more trouble than gains.
> Maybe for some users (on some systems?) they can work reliably,
> unfortunately not for me :)

This is my experience too.

+ Kdenlive project has no releases cycle designed to have really stable
versions.
p.e. Debian repositories have always a "casual" version that becomes
quickly unmaintained, and AppImages an similar downloadables are never
LTS versions.