-
Destructive edits
-
[Herb Sevush] “However, in the particular world of media work, the adjective “destructive” has a more specific meaning – it refers to making changes to files, whether audio or visual, that cannot be reversed and become “baked”into the file.”
Consider Photoshop. I blur a rasterized layer; that’s considered a destructive filter because it irreversibly alters its source, even if I have a backup copy of the original image.
Now if I blur a smart object instead, it’s non-destructive because the blur can be changed or removed at any time.
Here, I am showing an editorial operation that irreversibly alters its source (the timeline, not the media files), cannot be reversed and becomes baked into the file: the project file that is, not the media files.
David Lawrence has very reasonably declared the project file as the true digital master; I think that along these lines, the use of the word destructive to apply to media changes only is overly narrow, is inconsistent with its use in other media applications, and undervalues the data in the project file.
[Herb Sevush] “The original conversation was in response to labeling something a “destructive timeline.” Since all timelines, by the necessities of editing, can destroy information, what did it meant to call a given timeline destructive?”
Yes, I think the concept of destruction applies to operations, not to timelines.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
[Richard Herd] “It’s already stored as 99 undos on the wall, 99 undos, you take one down you restore the destructive edit…98 undos on the wall. ;)”
Heh heh.
But when you close a program, that undo cache gets flushed.
What if I moved, using Walter’s example, a clip back up out of the primary and that was originally placed 36 days ago? FCPX would have to remember, those 99+ undos, and where, specifically, that move was in the undo stack and what was happening with timeline around it, and then it would have to infer my intention of what I want to happen now.
No amount of beers on the wall would help me, except perhaps to lead me to forget what was going on the first place.
-
[Andy Neil] “All you have to do is use the trim tool to roll the edges of the clips in the primary back underneath the connected clip and then reposition the connection point for the connected clip so it’s back over it’s original. Does it take several steps? Sure, but it’s still non-destructive in my mind.”
So as long as you remember the way everything was, you can manually restore it and it’s a non-destructive operation?
[Andy Neil] “Now, contrast that with the Audio Mixdown in Avid. Here you set in/out and active tracks and then Avid makes brand new media with no relationship to the original clips, even combining multiple clips from different sources. The result is something that can’t be matched back to the original masters, has no relationship to anything other than itself and therefore is a truly destructive edit.”
As long as you remember the way everything was, you can restore it, right?
My point in all this is that we largely have been thinking of NLEs as non-destructive because they are non-linear, but that’s not the case. FCP X has shown how interesting non-destructive rearrangement can be. What if there were more operations that were non-destructive?
I suggested heat-mapping timelines [link] a while back, showing you which areas of a timeline have seen the most work. In Apple-speak, imagine if you could instantly make any edit a revision-tracking Time Machine Audition.
Idle chatter, but I think there’s still enormous room for innovation with editorial timelines. I’ll go file a few patents and we can come back to the discussion in 5 years.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
[Jeremy Garchow] “What if I moved, using Walter’s example, a clip back up out of the primary and that was originally placed 36 days ago? FCPX would have to remember, those 99+ undos, and where, specifically, that move was in the undo stack and what was happening with timeline around it, and then it would have to infer my intention of what I want to happen now.”
Don’t think of it as undo — think of it as saving the information than a destructive operation destroys and being able to recall it on demand.
If this editorial information were stored transactionally and linked to affected clips, locating and recalling “old” data wouldn’t be impossible or even particularly burdensome for a computer capable of up to 7 teraflops.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
[Walter Soyka] “Don’t think of it as undo — think of it as saving the information than a destructive operation destroys and being able to recall it on demand.”
I know what you’re going for, I was just using RH’s “99 undos”.
[Walter Soyka] “If this editorial information were stored transactionally and linked to affected clips, locating and recalling “old” data wouldn’t be impossible or even particularly burdensome for a computer capable of up to 7 teraflops.”
I don’t think it’s that easy. It’s not storing that information of that one move, it’s storing the relationship of that move plus everything that happened before and after it, in relation to time, not only physical time of how long ago that action was performed, but time in the sense of where it was on the timeline and what was happening around it? What if, when I move that clip up out of the primary, I don’t want it to restore what I did 36 days ago? Or there’s now a different clip next to the clip I am moving, or that clip is now above the original clip?
It just seems like a massive resource hog when as an editor, I can place layers above (or place clips in an Audition, or whatever) and have that stored information at my fingertips.
-
[Walter Soyka] “As long as you remember the way everything was, you can restore it, right?”
If you want to argue semantics then fine. I’m not saying you can’t do a destructive edit in FCPX, I’m saying your example is poor. I don’t have to remember anything about the previous position of your clips to restore them since in both cases the resulting video is the same. If at any time you want to delete that connected clip, all I have to do is roll those clips back together and check a singular edit point, the cut at which would likely be easily seen. It would the most minor of issues. The point is, I have full access to the original clips in the original cut and they can be restored with a minimum of hassle.
If, in your edit, you’d completely overwritten an entire clip, then that would be destructive because i’d have to manually go back through the clips in the browser and try to remember exactly what was there (as opposed to still having them there). Now, for this to be truly destructive, you’d need to overwrite audio as well as video. If the original audio is left in the timeline (which it typically is with Overwrite to Primary functions, then restoring the original edit is simply a matter of matchframing and replacing. To me, the issue at stake in a destructive edit versus a non-destructive one is the connection to original media.
Just like in the audio mixdown in avid. If you overwrite the original tracks with the mixdown, you have no way of getting those original tracks back because there is no longer a connection in the timeline for them.
Andy
https://plus.google.com/u/0/107277729326633563425/videos
-
[Walter Soyka] “Here, I am showing an editorial operation that irreversibly alters its source (the timeline, not the media files), cannot be reversed”
Hit undo, and it’s reversed. Most “destructive” operations don’t have an undo feature.
[Walter Soyka] “I think the concept of destruction applies to operations, not to timelines.”
We agree, and this was the essence of the other thread.
Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf -
[Andy Neil] “If you want to argue semantics then fine.”
Sorry, Andy, I’m not trying to be a jerk. Bill really got me thinking when he threw out the “d-word” in the other thread and got such a strong reaction.
FCP X has piqued my interested about the way that our applications try to encode our intent and help us with common problems. I’m not sure my posts have any practical value whatsoever, but after some really geeky theoretical threads a few years ago, this seemed like the place to discuss the theory.
I am looking at the information available in the timeline before and after an operation and its inverse. I am noting that it is altered, not perfectly restored.
I absolutely understand that this destruction is intentional and may even be desirable — but I am sincerely surprised that there’s debate over whether eliminating information from a project file is destructive or not.
In my example, destroyed information includes clip extents, a transition (cut only), and a connection point. Maybe it was poor — I certainly could have made it more comprehensive — but the point I was trying to make was that there’s a set of information that goes away after some (many? most?) editorial operations.
Auditions are cool, but I think there still may be lessons to learn from other adjacent areas, especially around proceduralism and version/change management.
For example, NUKE has local, per-node undo stacks. You can go back on a change in one specific node, even if you since made a zillion other changes in other nodes, all without having to reset the global state of the script. I think that FCP X’s magnetic timeline would be a unique advantage on per-clip undo, because reflowing the hierarchical timeline gives you clip collision avoidance for free.
Again — not trying to ruffle feathers, just trying to think outside the box a little.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
My feathers remain unruffled. I think the best way I can put this is that I feel your definition is too broad and my argument is for a more specific definition. I agree that destructive doesn’t mean bad per se, but it should refer to irrevocable or at least immune to a quickly changed mind.
Andy
https://plus.google.com/u/0/107277729326633563425/videos
-
[Jeremy Garchow] “I don’t think it’s that easy. It’s not storing that information of that one move, it’s storing the relationship of that move plus everything that happened before and after it, in relation to time, not only physical time of how long ago that action was performed, but time in the sense of where it was on the timeline and what was happening around it? “
All you need to do is store a complete history alongside the current state. You’d need organize the history to make it easy and efficient to use, but that’s not impossible. Even if it were too hard to do on the desktop, we could do it in North Carolina [link]!
There are certainly conflicts that could arise and require resolution; some subsequent operations should ideally block restoration of earlier ones. I think the hard part is a sensible UI moreso than the data management.
This would enable two killer features, which I’d think belong under the “Producer” menu:
1. Split the difference
2. Wait, I changed my mind on that other thing I said two days agoFor reference:
https://cgmemes.blogspot.com/2012/07/blog-post.html
https://cgmemes.blogspot.com/2012/11/efficiency.htmlWalter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn]
Reply to this Discussion! Login or Sign Up