Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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.
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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 > Datum: 09.05.19 21:00 (GMT+01:00) > An: Kdenlive > Betreff: Re: example project: 19.04 Multitrack compositing still broken: > differs from all previous Kdenlive versions back to 15 and before > > Hi Harald > > Let me start by saying how much I think you are a valuable member to this > community (see the Toolbox among many other things) and I think the devs > feel the same. I just cannot but help to dislike your tone. Although I can > TOTALLY understand your frustration with seeing your daily driver not work. > Maybe because i follow the difficulties of develoipment on a day to day > basis... > > Em qua, 8 de mai de 2019 às 14:43, Harald Albrecht < > harald.albre...@gmx.net> 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 la
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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
>>> Datum: 09.05.19 21:00 (GMT+01:00)
>>> An: Kdenlive
>>> 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
>>> 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 reaso
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
Le jeu. 9 mai 2019 à 23:40, Jacob Kauffmann 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
> Datum: 09.05.19 21:00 (GMT+01:00)
> An: Kdenlive
> Betreff: Re: example project: 19.04 Multitrack compositing still broken:
> differs from all previous Kdenlive versions back to 15 and before
>
> Hi Harald
>
> Let me start by saying how much I think you are a valuable member to this
> community (see the Toolbox among many other things) and I think the devs
> feel the same. I just cannot but help to dislike your tone. Although I can
> TOTALLY understand your frustration with seeing your daily driver not work.
> Maybe because i follow the difficulties of develoipment on a day to day
> basis...
>
> Em qua, 8 de mai de 2019 às 14:43, Harald Albrecht <
> harald.albre...@gmx.net> escreveu:
>
>
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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 > Datum: 09.05.19 21:00 (GMT+01:00) > An: Kdenlive > 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 > 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 almos
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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 Datum: 09.05.19 21:00 (GMT+01:00) An: Kdenlive 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 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 treatmen
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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.
Re: example project: 19.04 Multitrack compositing still broken: differs from all previous Kdenlive versions back to 15 and before
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.
