Yes. Keyframes for complex parameters like the colorgrading colors and rectangles do not allow manipulation in the keyframes panel. So they can have a shorter height in the keyframe panel. Keyframes for simple parameters can be manipulated in the keyframes panel - so they need more height.
I will not be too heavy with this to argue otherwise knowing all theall the work you developers do at Shotcut , and that the resources are surely better used in other developments. I understand that.
I just found it strange (in my inexperience) because as seen in the screenshots, the filters with reduced height in the keyframes panel, is so tight that it even seems that the icons almost do not fit.
I still donât see the advantages of having that short height by default, if there are other filters with normal height (with the same complexity).
Also, since it happens in filters with only one keyframe field, it doesnât seem to be space-saving (as it could happen in filters with 3 or 4 stacked keyframe fields) that are displayed at the same time in the keyframes panel.
Here is an example of two filters where I donât understand why that difference in height.
Brightness
Contrast
Good observation. Contrast should also be keyframes with curves like Brightness is.
That is a good observation and understandable. The reason has to do with the underlying implementation. The contrast filter actually uses the same code on the backend as the Color Grading filter. When you move the slider for the contrast filter, it has to do complicated math on the value to set the 9 values that are set by the Color Grading filter. That complicated math has not been copied into the keyframes code for that specific filter. And so you can not drag the keyframe values for the Contrast filter.
Maybe someday we will write new contrast code for the backend that does not require the complicated math so that the keyframes can be manipulated as you are expecting.
This release candidate will not be a general bug-fixing period. Only highly critical bugs and regressions since version v20.05.01 will be addressed.
I understand. Maybe something will change in the future (some library or who knows, I know nothing about programming) and it will be âsimplerâ to implement, or maybe it will be fixed just as a side effect of updating other things. Itâs not a critical thing for me, just exposing things when I see them.
I included it in this thread because I saw this behavior in this release. I didnât bother to see if this happened in previous releases (my bad) and never noticed it until now (Iâm a bit absent-minded a lot of times).
So just note this report somewhere if you think itâs convenient.
Sorry if I distracted from the more critical issues. I donât mean to.
I canât tell if these are critical. They appear to be regressions. This release candidate is exceptionally stable for me anyway.
-
Splitting or trimming a clip on the Timeline messes up the advanced keyframesâ positions if filter in point is set.
-
Start Delay in Timer filter is no longer effective if speed is changed from the default.
Letâs say I set 10 seconds as Start Delay.
If speed is 2.00000, the timer starts 5 seconds off of the start of the clip.
If speed is 0.50000, the timer starts 20 seconds off of the start of the clip.
There is now a Speed in the filter as well as in Properties. The contributor of Speed in the Timer filter did not make speed affect the interpretation of other time-based parameters. I do not know if that was intentional or an oversight. In any case, this will not be addressed for this release, and one needs to manually compensate for that.