I’m not sure if this has already been suggested, but I’ve searched throughout the forums and I couldn’t find anything. So I’m suggesting that keyframes should be added to more of the audio filters, such as high-pass, low-pass, band pass, delay, etc. Thank you and I hope that you all have a great day.
I decided to take a look at this. I was making a meme video and needed to keyframe the low-pass filter (and also reverb) but it wasn’t possible. Quite weird, I thought all filters can use keyframes. I dug into the source and today implemented keyframes for the low-pass filter, it’s not that hard but also not as easy as setting a flag “use keyframes” inside. Still, needs UI and logic modification in QML.
I want to know what UX is preferred for this. Shotcut allows to make separate keyframe tracks for every knob. But in 3eq filter, for example, there’s only one track and it’s not a “curve” track i.e. it’s not possible to edit the keyframe values directly in the track, they’re all squashed into “points” instead. Every point indicates that some values were changed at this frame but it’s not possible to see which exactly. However, internally this UI is easier to make and it wouldn’t clutter the keyframe timeline.
For LP I made three “curve” tracks (cutoff, rolloff rate, wetness) so I can see their values right in the timeline. However, it means that this filter alone creates three separate KF tracks. The logic is also a bit more convoluted because changes of just one knob shouldn’t create keyframes in other knob tracks. A compromise might be three different keyframe buttons that let the user animate individual properties.
Another question is whether “simple” keyframes should be supported (fade-in/fade-out). It’s a bit hard to figure out but looks like they’re sort of old and are converted into regular keyframes if the keyframe type is changed. It’s unclear if they should be supported for new filters.
I couldn’t find a UI/UX guide so am asking for directions.
This is a judgement call decision on a case-by-case basis. I do not think we have generalized guidelines for this. For the 3-band EQ, I combined the three parameters into one set of keyframes because I think it makes sense to modify all the values together. So you should consider the use cases for your filter. Are users likely to want to keyframe the three parameters separately? Or are they more likely to modify all 3 values at the same time?
You could post a screenshot of your progress so far and people could comment on that. Sometimes that helps to get feedback on the use cases for that specific filter.
Yes
They are not “old”. They are a simple way for a user to ease in/out values without dealing with many keyframes.
Thanks for the answers! This is what it looks like now:
It renders fine with the effect applied, however for some reason the rolloff rate keyframes don’t load properly; instead of multiple keyframes only the last one is shown at the very beginning of the timeline. I can’t find any differences between this one and two other tracks (that are loaded fine) but I’ll keep digging.
I suppose simple keyframes should map to wetness then. Ironically, handling them is more complex than “advanced” keyframes it seems.
They should control all of the keyframable parameters, which is basically redundant with what you are showing. Also, the span line of your keyframe button should not extend to the preset. The preset itself is not keyframable even though it can store keyframes. Also, I am not sure all of these parameters should be grouped like you have done. If you plan to submit it, I probably will not accept it as such. I do not want that trend to continue.
handling them is more complex than “advanced” keyframes
Perhaps, but you should try basing your filter UI on KeyframableFilter rather than Item or Rectangle to include common functionality. Not all filters are using it because it came later rather than first. Also, sometimes it does not help much.
Thank you for the feedback. Yes, I thought about splitting the keyframe button into three so it’s less confusing and more flexible. That’s exactly why I asked for guidelines, good to know that this is not how it should be 
I actually did that, will look into other filter sources. Probably I even had it working at some point without writing any code but then messed it up. I’ll post an update as soon as I sort it all out.
My opinion is that if you are going to show three keyframe parameters in the keyframe panel, then you should have three keyframe toggle buttons in the filter panel (instead of making them all share one stopwatch button).
I agree with Dan’s comment: It is good to start from a recent example that uses KeyframableFilter and then modify to match your needs for this filter.
This might be a good example to work from:
1 Like
Okay, I made some progress. Both simple and advanced keyframes work, the sliders can be animated separately. Keyframes are saved and loaded properly.
A couple of takeaways, however.
- the property
keyframableParametersisn’t set in the box blur filter mentioned above, as a result there are these warnings in the output when editing simple keyframes:
[Warning] <> "Could not convert argument 1 at"
[Warning] <> "updateFilter@file:///.../shotcut/src/qml/modules/Shotcut/Controls/KeyframableFilter.qml:99"
[Warning] <> "updateSimpleKeyframes@file:///.../shotcut/build/share/shotcut/qml/filters/blur/ui_box_blur.qml:59"
[Warning] <> "expression for onAnimateOutChanged@file:///.../shotcut/build/share/shotcut/qml/filters/blur/ui_box_blur.qml:144"
[Warning] <> "onPositionChanged@file:///.../shotcut/build/share/shotcut/qml/views/keyframes/Clip.qml:408"
[Warning] <> "Passing incompatible arguments to C++ functions from JavaScript is dangerous and deprecated."
[Warning] <> "This will throw a JavaScript TypeError in future releases of Qt!"
The filter itself works correctly but it still needs to be fixed. In my case in the lowpass filter it caused some weirdness like overflowing sliders when changing simple keyframes. After I set this property as keyframableParameters: ['0', '1', 'wetness'] it was all fixed.
- I don’t think simple keyframes should be applied to all properties in this filter. I don’t personally find it intuitive, if I want this sound effect to fade-in and fade-out I expect the
wetnessparameter to change but not the cutoff/rolloff frequency and wetness at the same time. Just wetness changing is what I’d want. I realize it’s not a universal rule and should be probably judged on a case-by-case basis.
And a quick question, in this situation should I include all properties to simpleProperties in meta.qml or just wetness?
All in all, the common functionality in KeyframableFilter covers everything really good so if this UI/UX looks nice I can post a PR shortly and then add keyframes to more audio filters.
It is the general behavior of all filters that simple keyframes include all keyframable parameters. Previously that was not always the case, and it was unclear to the user which were included. However, I do agree that in a case like wetness it makes sense. Some people have requested something like an opacity control for all video filters to control blending of the filter’s effect with the previous image state, but we direct people to the masking filters for that. I am willing to accept wetness only in simpleProperties (but there is more to simple properties than that). It is normal that you need to set keyframableParameters when using KeyframableFilter. Probably that filter is not the best example of using KeyframableFilter because it appears to not use many of the common functions, but it can be a good example of using some parts and not others so you can have a different set of properties between simple and advanced.
1 Like