As @musodata reported in this thread, I thought it was a kind of bug for a long time. And I was always embarrassed when showing this to people (pro and non pro video makers) I was trying to convict that Shotcut would be a production-ready solution. The reaction of “Why THIS” was always here.
Like @Austinsaid this “feature” makes the rearrangement of crossfades absolutely impossible; so this makes the whole crossfades feature unusable.
Here again I tried to jump onto the code but … I’m still unable to compile (I saw that another guy had some hope at some point, but because of the auto-closing feature of the forum anybody can ask him how does it goes for him without opening a new thread ).
Do you plan to put a dynamic crossfade on the roadmap someday ? Or is it a a wasted effort to argue ? (like here)
Sorry for the negative tone here, I’m globally tired and almost on the point to buy a proprietary software (Vegas, not to quote it). For me it’s a big fail in my free software advocate life.
Altough i don’t see it as dramatic as brunetton, i have to agree with his points.
Crossfades are one of the most important features in video editing and the behavior in SC in this respect was quite confusing for me, the first time i used it. If i want to change the crossfades on multiple clips overlapping its a pain in the ass. I ended up deleting all crossfades, registering that parts of the original clips get ripped as well, so you have to do all these parts again.
If you know the behavior you will find workarounds over time - but its still unnatural and really a big pain.
If it would be possible to do dynamic crossfades with editable parameters it would be really a great improvement in SC.
This is actually quite dramatic for me. I mean this is obviously not the bigger problem in my life but this is a fact: I need a video editing software on Linux for some paid jobs I do (shortfilms with teenagers for schools). As I’m an open source developer I’m trying my best to limit my software usage to open source. For some of them this is super easy and natural but for some others this is really painful and time consuming.
And I feel it too bad to see a such good rendering engine, with a such great UI globally speaking (compared to other open source NLVE softwares) with points like this one that prevents me (and I presume the most part of users that tried, and finally gone to download Davinci Resolve, but of course nobody can prove this, nor the opposite) from using it
I mean, I’m actually using it, but only for super short projects for family films, that limits to 3 or 4 clips on 2 video tracks; without the need to make precise crossfades but I do not use it for bigger projects (more than 100 video clips on the timeline).
It’s like having a Ferrari for free (and thanks a lot for that, of course, I should have insisted on this point) but being only able to turn left, not right because the designer of the Ferrari decided that going right is not really important; and anyway if I want to go right I can still turn left for 270° and this will do the same.
This makes me super sad for the time and energy you gave to the project for years. If you do not listen to users needs, unfortunately the project may be less and less used and supported => don’t you feel this like a little drama ? I feel it this way. Even more because users are not migrating to another open source solution, but very probably for proprietary softwares.
If I were rich and had time I would definitely initiate a fork of the project, with the specificity of users-need governance. I mean: users would be the ones that decides of the next version improvements. By voting typically. Using an open source video editor for paid projects is a teenager’s dream for me. I started some proof of concepts of NLVE softwares when I was a student but never had the time to make something usable.
But there are solutions IMHO: why not asking to users what they need the most ? Like voting for issues/suggestions they want to be taken care of ? If you propose me to pay to support a dynamic crossfade development tomorrow I’m in!
Thanks for suggestion. I’m aware of the slideshow function. This is everything but a viable answer to the subject here; I don’t think you got my point (I’m actually thinking of how could I explain the need).
It’s hard to explain to people that hadn’t done “real” video montage for TV or cinema (with hundred of video and audio clips) why this need is more than “important”.
I’ll probably make a video to show the need; that would be clearer than words.
Because the issue is a lack of resources. It’s basically just two developers working on Shotcut. On top of that Dan is also developing MLT. That’s two open source projects he is developing at the same time. If they had more hands in the mix then the development would move faster.
I do not want to escalate the drama … but I truly do not understand. This reflects my own lack of experience - the video clip you linked to in the first post was the first time I even thought about something like this. Can you help me to understand how the function you are asking for is different from the Slideshow function? (Again, sorry for my inexperience.)
On edit: I just experimented to see how the Slideshow actually works - it seems to be able to do exactly what was shown for “automatic transitions” in the YouTube clip in post 1. Yes, it can be used with stills … but it also works perfectly with videos (at least in my limited testing). The only catch is that you need to set the duration to be at least as long as the longest video; otherwise, it will “clip” the videos to the duration length. (That might actually be a useful feature in some situations …) So working with videos of, say, 10s to 5m in length, set the duration to 300s or more, and voila! The clips are put in (and no, they are not stretched to 300 seconds - if it is a 10s or 2m video, it goes in as 10s or 2m, or so on) and the transitions are applied.
This is mainly about being able to adjust an existing single transition’s duration by dragging a clip. In Shotcut today you can only adjust the duration by dragging the trim handles and only if there is additional footage to expose when extending duration. Additionally, dragging a trim handle does not adjust each clip by an equal amount.
I’m perfectly happy right now to be able to edit a transition’s length by moving the handles. But I have to say that what we see in the Sony Vega tutorial looks nice. If Shotcut comes one day with that feature, I won’t complain
Sorry for the late delay. Yes I’m a developer, with a master degree, and 20 years of experience.
Participating instead of complaining sound absolutely great to me, and very exciting ! I always dreamed of doing an open source video editor, and ShotCut is by far the best project in this domain IMHO.
But as always, the time <-> money dilemma comes into play. I unfortunately can’t afford spending one week to understand the project architecture and some weeks more to code on this project without some financial compensation. Still, I can “prove myself” to the team for free if they want a “free sample”, for a “little” project I find it absolutely normal.
But I’ve to admit that I’ve been discouraged by my fails attempts to build the project, even with the kind help of @brian and @shotcut.
If the situation has been improved since, I’m still motivated to compile and get started to contribute ! (and stop complaining )
The build script on Ubuntu is still the fastest way to get going. The last time I reinstalled Linux, it took me about 4 hours to restore my Shotcut working environment - including discovering and installing all dependencies.
You can copy/paste the dependencies from the Docker build file:
You can see an example of the script configuration in the github action file:
A great contribution for a new user would be to document the process to build Shotcut from scratch.