Sorry about that! I’ll send you a Starbucks card. =)
2 Likes
And I spilled an entire 6-pack of beer…
1 Like
@bentacualar, I think a queue is forming. Better get your wallet out.
2 Likes
I better start selling Shotcut hats to cover expenses…
2 Likes
LOL. You could probably get a lot for yours on the black market … 
2 Likes
That could’ve possibly been built in the algorithm…
2 Likes
Time Remap is the same as DaVinci Resolve when using Resolve in Retime Frame mode.
DaVinci Resolve has three ways of changing speed.
This method (Change Speed) is basically the same as Shotcut’s Properties > Speed setting:
This method (Retime Speed) is like the graph that @bentacular demonstrated:
This method (Retime Frame) is the same as the Time Remap filter today:
All of these methods are demonstrated by this YouTube video:
https://www.youtube.com/watch?v=UkXg0SywwR8
The reason Resolve supports both Retime Frame and Retime Speed is because Retime Frame (Time Remap) can do things that Retime Speed (a speed line) cannot do – specifically, go in reverse and freeze frame without having to split the clip. A speed line is always moving forward through time. There is no method for indicating 1x Reverse or total freeze on a speed line. A speed line is still super useful, but this is the tradeoff for simplicity.
An additional consideration that makes Time Remap powerful is when setting in/out points for speed zones. Using the example of a skateboard video, let’s say we want to retime a jump from wheels up to wheels down. In Resolve, it’s possible to place markers at these points, and then shift the speed curve between markers which interactively changes the length of the clip on the timeline. But Shotcut does not have this level of interactivity with timeline clips today, or markers. The unfortunate side effect is that a speed line won’t retain the same in/out points if it is later modified (under current Shotcut mechanics).
Let’s say the skateboard is in the air with 0.5x slow-mo but now we want to change it to 0.25x slow-mo. Because the speed is twice as slow now, the keyframe to return to 1x speed needs to be moved twice as far down the timeline to remain synced with the wheels landing. This would be a manual hunt-and-adjust operation for every speed change if using a speed line, because speed is by nature not locked to a specific frame in the source clip. In essence, the out point will drift. This hunt would not be necessary with Time Remap (especially if ripple was added) because the Y-axis can be locked to hold the out point constant (it would always point to the frame where the wheels landed), and then the X-axis can be moved independently to make the slow-motion last longer or shorter. This feature cannot be overstated in its value.
@brian Speaking of ripple, as indicated by the screenshots above and the linked demo video, Resolve has support for ripple, and it seems pretty integral to a fast editing workflow. When the clips on the timeline interactively change length and shift position, that is also implicit ripple at work. The strict left-to-right workflow hasn’t been used in Resolve since at least version 15 because markers that locked in/out points constant were a game changer. Other editors, I’m not sure. In lieu of markers, rippling keyframes in Shotcut would get 95% functionality without having to code an entirely new marker paradigm.
Back to my overall point … Time Remap and Speed Line are two entirely different concepts that can be implemented with two entirely separate filters, allowing the user to choose which one they prefer for each scenario. This is how Resolve handles this situation. There is no reason to convert Time Remap into a Speed Line today. And there is no reason to combine both concepts into one filter … in fact, it logistically cannot be done.
My personal approach is to mentally accept that the Time Remap filter is most similar to Retime Frame in Resolve, and that its graph will be fundamentally unique among all other filters simply because it can go in reverse.
Resource-wise, I feel this is an excellent first filter for time manipulation in Shotcut because it can do everything a speed line can do and more. It’s the most powerful and comprehensive of the three Resolve options. But to everyone’s point, the quality of its documentation will make or break it. If Time Remap simply doesn’t get enough traction with Shotcut users, there is always the option (developer time and interest permitting) to add a second filter that is more similar to Resolve’s Retime Speed. But again, these are two fundamentally different and incompatible ways of manipulating time which cannot be combined into one filter. Therefore, I’m grateful that the most powerful option was chosen first so we have access to full retiming potential right away.
P.S… I’m aware that most open source projects do not aspire to be duplicates of commercial options. OSS programs have their own methodologies. I mention Resolve simply as a reference point for users with prior retiming experience.
4 Likes
Exactly. I think it may be overly ambitious & confusing to jam too many features in one filter.
2 Likes
I have just spent the past three days completely rewriting a software project of mine (a WordPress theme, unrelated to anything video). Over the past month of PHP editing, it had become a bloated and crashing nightmare.
When I realized that I had conflated several distinct functionalities, attempting to implement all of these functionalities in one module, I split it into three modules.
Instead of becoming larger, it became much smaller, cleaner, easy to understand and easy to maintain.
I corrected my error of trying to do to many different things in one piece of software.
It makes the current project under discussion look very familiar.
Been there, done that, far too many times.
…and I did it again.
I should learn better.
1 Like
Well said. For me Shotcut gives me the expectation as a software that’s aiming to streamline but not dumb down the process of doing things that in other software has more steps. So in Shotcut you can achieve things with a lot less clicking. For example, a lot of people like how easily transitions are done in Shotcut. Another example is the proxy workflow which may be the most streamlined proxy system of any video editor I know proprietary or not. I admit I didn’t get the proxy workflow at first but once I understood it I felt @shotcut knocked it out of the park. It’s pretty hard to go back to the proxy workflows of other editors that have a whole menu to go through whereas with Shotcut it’s literally just one button maybe two.
I hope there still could be some modifications to Time Remap to help make it more intuitive. @Austin actually touched on something I was going to mention in a post I was planning on writing. I’ll bring it up later.
Now @brian did say before that Time Remap is not meant specifically for speed ramping although of course it can be used for that. However, whenever development for a speed ramping feature is made for Shotcut, I believe serious consideration should be given to Final Cut’s speed ramping feature to use as inspiration for development of one. I’ve never used Final Cut but I’ve seen videos of it and its speed ramping feature is streamlined in a way that would fit with Shotcut. It doesn’t use keyframes per say but instead sort of splits a clip into sections with the desired speed changes and in between those split parts sections are added where the ramping occurs which can easily be made longer or shorter similar to how transition clips work in Shotcut.
Here’s a video demonstrating it:
youtube.com/watch?v=9fV9CLPoeGY
I’ve actually seen Resolve users express that they wish Resolve would modify their Speed Ramp feature to be more like Final Cut’s since it’s much faster and easier to achieve the same results. So when the day comes to develop a speed ramp feature for Shotcut, I highly recommend using Final Cut’s speed ramping as inspiration.
2 Likes
I think the same thing is happening here. Time Remap is different than other filters, yes. But once users grasp the way it works, nobody will want to give it up. The key is good training rather than reducing functionality of the filter. It works identical to Resolve and nobody is telling Blackmagic they were too ambitious.
Now, if somebody wants to say that Speed Ramp and Time Remap should have been released at the same time, well, that’s a whole different conversation. Given infinite developer resources, I would agree. 
The ambitious goals and pace of the project are to be lauded.
Blaming all of the bumps in the road along the way to achieve that goal in such an ambitious timeframe, upon the limited resources of the beta testers, well, that is a different story.
I don’t understand what you’re saying.
Upon review, I see two types of objections with Time Remap during its rollout:
- Usability issues that have resulted in tweaks like the speed-setting buttons, as suggested by testers and implemented by Brian. Great teamwork.
- People with fundamental objections to the time slope concept and who wanted the mechanics changed to a speed ramp. Simply put, this is not their preferred filter for this task. A dedicated speed ramp filter can come later and then everyone is happy. It is fundamentally too different to merge into Time Remap.
The #2 conversation is not productive. There’s more value in focusing on what we do have rather than what we don’t have. Brian and Dan worked hard to make this possible. I hope they are encouraged rather than discouraged when they read through this thread. Encouragement is more likely to happen when people accept the filter for what it is and work within its parameters. It’s extremely powerful just the way it is.
1 Like
As people say here in Louisiana, “I have no dog in that fight”.
If I have been seen as taking sides, I have not been sufficiently clear. (nothing new there.)
An observation, not an objection:
Just as this is “fundamentally too different to merge”, I believe that because Shotcut is not Resolve, and has a filter UI that is highly commended for its ease of use, one of the ways it is different from Resolve etc. etc., the Time Remap is “fundamentally too different to merge” with the Shotcut legacy filter UI, and I perceive (and I could be wrong) that this will continue to produce headaches until a separation of UI is made.
Yeah I understand the basic core of it as I was testing it on and off for the past few months. But there are things that still need to be improved upon and modified. Like I said, I wish I had more time to test it during the past few months like I did before. It’s great that @brian still wants to improve on the filter so I’m looking forward to how it will mature.
Well, not identical. Sadly Smooth keyframes have been disabled because its algorithm doesn’t jive with Time Remap. Also, remember there is the B frame issue which actually does put a limitation on it. I’m glad though that my suggestion for a sub-clip option was added to Convert To Edit Friendly as it least it does mitigate the problem a bit. That B frame issue is on FFMPEG, right?
@brian, I don’t know what the rapport is like with the Kdenlive team, but I saw that they announced they are planning to add their version of a Time Remap feature. I’m wondering if it’s possible to ask them if they would be interested in helping to improve the Smooth keyframes issue so that it won’t be such a daunting task. It would benefit both programs after all.
By the way, @Austin have you finally tried Shotcut’s proxy workflow? 
You can basically use that argument in any case whether the design is good or counterintuitive to anything else in the software. We can start adding functionalities where keframes are controlled by semi-circles. Can we eventually train people to accept it? Yes. Is the UI consistent with all other functionalities within Shotcut? No.
It’s a problem when even the “trainers” don’t how how to train others on the functionality. Can it be designed easier so that it can “help the helpers”? Absolutely.
There is nothing more I’d love to do than to create a tutorial video about this functionality (it’ll shamelessly plug my channel). But I can’t even make sense of it, and the hundreds of questions I will get, I can’t say I’ll be able to answer it nor support the mindset of why it was created that way, when there could’ve been a super-dumbed down version of it.
In interesting study was done a few years ago about "intuitive " interfaces. They found that the general population divided very neatly into two distinct groups:
- Those who found the Windows interface intuitive
- Those who found the Mac interface intuitive.
There were very few in the “both” or “neither” categories, and the studies were successfully replicated.
The results could be restated:
- A majority of people intuit the way Bill Gates intuits
- A significant plurality intuit like Steve Jobs.
(or did I get that backwards? )
“Intuitive” is a very slippery term.
1 Like
In this sense, it’s intuitiveness in the Shotcut universe. If it made sense in this universe that up is always more and down is less in a linear fashion, all of a sudden reversing it to down is more would make it seem non-intuitive.
P.S. Early Windows and Mac OS were basically derivatives of each other…
1 Like
I was involved in the development of a licenced pre-Windows-release “Windows desktop computer”.
We were running Windows 1.0 Beta on it.
It was nothing like the Mac.
I loved it.
(Many years later, I began buying Windows Phone 7 (then 8, 9, 10) smartphones because they had the same interface, an upgraded MS/DOS 4.1)
Then Bill Gates went to a trade show where Steve Jobs debuted his new “Desktop” vision, and Bill saw which booth was getting the biggest crowds.
Suddenly the “Desktop”, visually, was nearly the same as the Mac desktop, an untidy clutter of icons.
But the functionality, the way programs are referenced, the way programs are installed, what is handled for you by the system and what you must do for yourself, were very different.
Over the years, these differences have diminished, as Mac OS, Windows, and Linux all have moved towards a common accepted standard way of doing things.
1 Like
Duly noted. I’ll keep that in mind. I have some ideas how I could implement ripple.
Thanks for clearly explaining this distinction to our community members.
That sounds promising. I would be happy to collaborate.
If nobody else gets around to it, I will probably implement at least one new keyframe type. It would be similar to smooth, but it would guarantee to never go backwards. I am sure that people will request bezier curves with configurable control points. But I feel that will complicate the UI and and the code. So hopefully it doesn’t have to come to that.
1 Like