*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY The "Pitch compensation" option in the clip speed editor is disabled with the tooltip, "MLT must be compiled with rubberband to enable pitch correction." I have rubberband installed (via homebrew) and my kdenlive version is 24.05.0 downloaded directly from the dmg on kdenlive.org (which is really the only way to install it on MacOS.) I am running MacOS 14.5. STEPS TO REPRODUCE 1. Install kdenlive via the dmg from kdenlive.org 2. Import a clip with sound and drag it into the timeline 3. Right-click on the clip and choose "change speed" OBSERVED RESULT The pitch compensation option is grayed out and unusable. EXPECTED RESULT The pitch compensation option is enabled and fully usable. SOFTWARE/OS VERSIONS Windows: macOS: 14.5 Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
I also tried installing it via homebrew and ran into the same problem. This makes sense because homebrew simply installs the app from the dmg file downloaded from the website. The only way I actually got it to work was by manually compiling MLT with my system (rubberband included) and haphazardly replacing the relevant files inside the kdenlive.app/Contents/ application container with the ones I had just compiled, since Kdenlive, when built for MacOS, only uses the libraries inside the application. This isn't sustainable because updates would replace the application and overwrite it again with faulty libraries. I wonder whether this issue could be solved by altering the compilation environment with which the MacOS build gets made.
My attempts to compile mlt from scratch also seem to break seemingly unrelated things whenever I try, like rendering when including images in the timeline or random audio issues.
At this time, my workaround is to run kdenlive inside an arm64 Fedora/KDE VM.