![]() ![]() The majority of the editing experience has been great and I'm impressed with the speed and power of editing in Resolve. I've been using Resolve for grading for years, but only recently started using it for editing as I shot tons of BRAW footage for a client that I have been creating over 5 hours of content for. I do have a couple of iZotope plug-ins installed, but haven't had them applied on the timelines where the "undo" bug has occurred. So, it's kinda breaks the undo as it gets filled up with all value changes applied by iZotope and makes it seem that the undo function is broken. Sorry for the long response.Jamie LeJeune wrote: Do you have any iZotope audio plugins applied to the clips? I've noticed with iZotope plugins like Dialogue Denoise that respond dynamically to the audio content of the clip, the plugin is actually setting values as the clips plays, and those values are recorded in the undo history in Resolve. No need to try and find them in the timeline. When you try this it feels very intuitive and lets you go back to see your previous edits by just doing undo/redo. Just tried in Avid Media Composer and it works this way as well. I didn't know this before but just tried it and so it is. Note that what I describe is how FCP7 worked. Since the playhead is somewhere else, a different place would be bladed. This is not true with the current implementation. Typing Cmd+B again right now would do the same blade command as before. The playhead and scroll position are back to where they were before the user did the blade command. Everything now looks just like it did before the blade happened. RESULT: The undo stack is popped, the operation undone (as it is currently) and then the playhead position is restored to where it was before the blade had happened. undo/redo records the playhead position, does the blade, and records the resulting (again unchanged) playhead position. The previous blade edit is no longer on the screen and, in a real project with many clips and edits, it would be hard to find it again.Ĩ. undo/redo records the playhead position before doing the blade, does the blade, and then records the new playhead position in case the command moved it.ħ. Scroll a few screens forward in the timeline and move the playhead thereĦ. ![]() RESULT: Nothing happens because playhead movement isn't an Undo-able action.ĥ. Open a project with a timeline open and media on it. It just restores the playhead to where you had already put it.ġ. At this point Resolve would restore the playhead to where it was before the action was done for Undo and after the action was done for Redo. ![]() The only time Resolve moves the playhead is when an Undo or Redo command is executed. Thus the undo/redo stacks are composed of actions with associated playhead positions. The playhead is not moved - only recorded. When you do an action, the position of the playhead is recorded, then the action is done, and then the final position of the playhead is recorded. The simple answer is the playhead goes to where you'd placed it before you did the action. ![]() For example, ripple trimming or speed changing when using a reference audio cue is a prime example of an exceptionally common task that performs the edit away from the playhead. I'm sure there are more examples of where this is either undesirable or would require aggressive assumption-making from Resolve.Įikonoklastes wrote:There are several actions where moving the playhead from where it currently is, on undo, would be undesirable. Which part of the gap does the playhead go to on undo? You've brought the clip's in/out point to the playhead, but also introduced a gap. For example, ripple trimming or speed changing when using a reference audio cue is a prime example of an exceptionally common task that performs the edit away from the playhead.Īlso, how do you deal with slip and slide edits? With these you are editing in and out points simultaneously, so where does the playhead go?Īlso say you've pressed E to extend an edit to the playhead. There are several actions where moving the playhead from where it currently is, on undo, would be undesirable. If you are unsure what was undone, you can check that by looking at the undo history in the menu. Returning the playhead and timeline to its state immediately before the edit occurred makes it a whole lot easier, avoids inadvertent undo's, and positions the playhead for a correction, if one is wanted. I can't tell you how many times I've hit undone and have no confidence at what's occurred. John Paines wrote:Here's a vote for this one. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |