-
Destructive edits
-
If the edit was good it doesn’t usually take much time to recreate it from a scratch. That’s why I stopped using “versioning” by saving projects or keeping several sequences of the same scene with different variants long time ago. I only keep the versions with client’s comments.
-
[Mark Suszko] “As a guy who learned to cut and splice 8mm film as a child, then to edit B&W video by manually punching in and out on two open-reel EIAJ video recorders, using a stopwatch and china marker, and about 15 years doing linear A/B-roll umatic and beta to 1-inch editing, I look at your discussion of “destructive” editing and all I can say is: “Aren’t they cute.””
I learned to edit on linear Umatic systems (where you had no undo, but where you could redo as many times as you wanted). That background is actually part of my line of thinking here.
A video track on tape is a physical thing that can only hold one stream of video, so edits to that tape are necessarily destructive in the DHL sense of the word.
NLEs treat tracks (and lanes) with the same single-stream limitation by convention, not by necessity. They are assuming a limitation of their predecessor system that is not inherent in their own design.
We can argue the semantics of the word destructive all day. I think there’s plenty of supporting evidence for David’s use and for mine, approaching the matter from different backgrounds as we are — and as Jeremy rightly points out, a complete history may well be too unwieldy to be practically usable — but at the same time, I think there’s a lot of operational data we generate that’s way more ephemeral than it needs to be. Computer systems can change the way we work here, if we care to build them that way.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
[Walter Soyka] “I think there’s a lot of operational data we generate that’s way more ephemeral than it needs to be. Computer systems can change the way we work here, if we care to build them that way.
“Exactly. And isn’t that precisely how the designers coded X?
The way it handles standard editing operations – with the ability of the program to move timeline elements out of the way to eliminate a common way that a user might destroy their prior editing intent – is “less destructive” than the way other NLEs operate?
That’s where this started, after all.
In X, Position mode is OFF by default. Ergo, X is designed to be less “destructive” of the editors intent by design.
My initial argument, writ clear.
Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.
-
[Michael Aranyshev] “If the edit was good it doesn’t usually take much time to recreate it from a scratch. That’s why I stopped using “versioning” by saving projects or keeping several sequences of the same scene with different variants long time ago. I only keep the versions with client’s comments.
“This brings up good points.
When Apple engineers added Snapshots to fcpx, it made me think about why Apple chose the word “Project” for a sequence that we have debated on this forum.
These days, I barely make a new timeline, I simply keep working on the same Project, and make snapshots. This also fits in to (for now at least) the one timeline open a time design that is currently present in fcpx. My timeline really is a Project instead of a sequence.
If I need multiple Projects per Library, I, of course, make a new Project and snapshot that one as well.
To Walter’s point about Time Machine being a way to negate the undo, Snapshots certainly have that capability as long as you remember to snapshot often.
Now, some might say that Apple has walked back these capabilities after that initial X backlash at launch, but this design, when you really step back and take a really good look at it, seems pre-conceived to me, right down to the windows that snap open and closed (scopes, angles, inspectors, etc). It’s a pretty efficient use of space and you can open or close exactly what you need.
Not everyone may not like the design or capability, but it doesn’t feel like a haphazard development effort as the pundits may claim. It’s still a younger application.
-
[Bill Davis] “The way it handles standard editing operations – with the ability of the program to move timeline elements out of the way to eliminate a common way that a user might destroy their prior editing intent – is “less destructive” than the way other NLEs operate? That’s where this started, after all.”
Yes, this is where we started, and you call me obsessive. Where to stat – let’s try this phrase – “where a user might destroy” – yes the mighty use of the word “might.” You and I have already established that it is only a novice user who “might” destroy, that for many years you’ve ceased destroying anything at all. But now your back to characterizing something on the basis of what some unnamed and undefined operator “might” do – as opposed to describing what the timeline actually does.
Both timelines are destructive – you can delete clips in X, you can delete whole sections of the timeline. Both timelines give you tools to avoid clip collisions – X’s tools are simpler to use and more automated, but we both know that clip collisions are totally avoidable with any timeline. The only difference is the speed of the action – yet of all the differences between the magnetic timeline and traditional timelines – auditions, connected clips, roles, lack of fixed tracks – your choosing to distinguish the 2 timelines solely on the basis of how they differ when a novice user chooses to move clips. I wonder why.
And to Walter – this is precisely why David L. and I have bee arguing for a strict and narrow usage of the term “destructive.” In it’s narrow use it actually gives essential information to an editor – if you do this operation, a permanent change in your media will be one of the outcomes. This information allows the operator to make choices, like making a copy of the media in it’s present state, or choosing a different function that’s non-destructive to achieve a similar end. The operations in question have names that do not indicate the nature of the change – “flattening” or “noise reduction” need the explanatory “destructive operation” to warn the user. Overwrite or delete need no such designation. Calling an “overwrite” destructive is a waste of eleven letters.
Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf -
In that context, “irreversible” or “irrevocable” is a better word than “destructive”. You’ve permanently altered, not destroyed.
-
[Herb Sevush] “And to Walter – this is precisely why David L. and I have bee arguing for a strict and narrow usage of the term “destructive.” In it’s narrow use it actually gives essential information to an editor – if you do this operation, a permanent change in your media will be one of the outcomes. This information allows the operator to make choices, like making a copy of the media in it’s present state, or choosing a different function that’s non-destructive to achieve a similar end. The operations in question have names that do not indicate the nature of the change – “flattening” or “noise reduction” need the explanatory “destructive operation” to warn the user. Overwrite or delete need no such designation. Calling an “overwrite” destructive is a waste of eleven letters.”
Herb, I understand and agree with David’s request for clarity. I’m just opposed to his claim that there is one strict technical definition of “destructive” because his definition runs contrary to the way the word is used every day in image editing.
Now maybe the term has been misappropriated by the photography/design community, but it’s out there in very common use, and much like begging the question versus raising it, I don’t think you can get back the original meaning.
Before this thread, I naively assumed that we could have all agreed on a kind of colloquial definition that destructive operations “eat” their sources — that a destructive operation alters the input directly, and that a non-destructive operation modifies an object’s output.
I like this definition, because it fits the way “destructive” is used today across disciplines, whether we’re talking DAWs or image editors. For clarity, we can still explicitly state the scope: “destructive to source media” (really extreme!) or “destructive to a layer” (maybe not so bad).
We can use the term “committed” here (though I think it can suffer the exact same imprecision that “destructive” does, and as I mentioned above, I don’t think it will supplant usage of the word “destructive” outside of this thread). I don’t really care what the language is — what I’m interested in is the concept.
My first line of thinking, a way to keep everything live forever, does sound like a nightmare. But there’s more here to explore.
My basic premise is that if you look around at other DCC applications, you will see that they are generally trending away from requiring that the user commit to decisions. They are building abstractions around their original, decades-old data models and allowing the user to build a structure around some values that you can change it any time, with that change rippling through the entire piece of work.
A quick example: in an image editor, I have two ways of applying a levels effect. I can apply it directly to a raster layer (“committed”), or I can apply it to an adjustment layer above the raster layer (“uncommitted”).
In the first “committed” scenario, the original layer’s pixels are altered, and my levels parameter are baked into the layer, and once I start building on that layer, undo history won’t help me meaningfully get them back without also removing subsequent work.
In the second “uncommitted” scenario, the perceptual output is the same, but the original layer is not altered. The levels adjustment is kept fluid, and I can go back at any time, at any point in the work flow, and adjust the parameters.
From the perspective of the timeline, NLEs lack uncommitted toolsets. Every operation in the timeline is direct and committed (relative to the timeline, not to the media).
Imagine an L- or J-cut. With our committed NLEs, we may cut the two clips into the timeline, then roll and trim the video and audio separately. The original clip extents are eaten by these operations. All subsequent operations in the timeline are made relative to its current state, never to its original state.
With an uncommitted NLE, the L/J-cut could remain parametric. We could retain the original video and audio extents, and apply the L/J-cut on top of them, with the L/J-cut modifying the video and audio extents separately. All subsequent operations can be made relative to the original rough cut. (Something like this is easier in FCPX with its relative timeline because it has an easier structure for temporal reflowing than a traditional open timeline.)
Something along these lines would be in keeping with the trend I’m seeing in other DCC applications.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
[Walter Soyka] “Before this thread, I naively assumed that we could have all agreed on a kind of colloquial definition that destructive operations “eat” their sources — that a destructive operation alters the input directly, and that a non-destructive operation modifies an object’s output.”
This wider definition is fine so long as its understood that every time you modify a clips length or position on the timeline you are committing a “destructive” act – every time you trim, move, slip, slide, or delete a clip, or group of clips, every time you change an opacity level or color correction you have committed a destructive act. Under this definition pretty much anything other than assembly is destructive, at which point the phrase becomes close to meaningless, except when using adjustment layers or maintaining some kind of dynamic history, neither of which is very prevalent in most NLEs.
Adjustment layers are now in use with Ppro, but if I change a value in the adjustment layer, an opacity value lets say, isn’t that destructive as well, since I no longer have the value of the original opacity setting in that adjustment layer? To me adjustment layers are non-destructive only in the narrower sense of the word – you haven’t “baked anything in” to the way the media is presented. But you will lose information as soon as you change the adjustment layer itself, its just that this loss of information does not equal a loss of future choices.
I think I like this better; an act is destructive when it limits the future options you have in regards to both the media and its representation in the software. Once you’ve added a blur and flattened a layer you no longer have the choice to work with an unblurred image in that object – it doesn’t have to have blurred the original media, but it does have to affect the object you are working on in an irreversible way. A deleted clip can simply be edited back into the timeline, you have that choice. A flattend image cannot become unblurred, no matter what you do. You can create a whole new object using the same media, but that’s not the same thing. I think.
Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf -
[Walter Soyka] “From the perspective of the timeline, NLEs lack uncommitted toolsets. Every operation in the timeline is direct and committed (relative to the timeline, not to the media).”
[Herb Sevush] ” … an act is destructive when it limits the future options you have in regards to both the media and its representation in the software.”
Three further thoughts on this.
The first is that this revolves around the idea of a meaningful memory of decisions. Over the course of an 8 month edit, I am not sure that every past iteration of every clip and clip order and fine adjustments and filters and levels etc. necessarily represents a meaningful record (ie. one that can be put to use well). The idea of “versions”, “snapshots” etc. stands at the other end of the scale – in other words, one is an automated recorded of everything, the other is a selective and intentional record of what the editor chooses as meaningful (something she might want to go back to).
Another idea (alluded to by Walter) is the contrast between a trail (an undo stack) and “random-access” uncommitted decisions. One only traces back things in the order you’ve executed them, the other allows you to change any decision at any time. I’m not sure image-editing is a good model for NLEs with respect to the implications of each method.
Finally, as I mentioned before, I think the current nomenclature is important.
If not “committed / non-committed” then “undoable” indicates a certain relationship with things you are doing in the software. “Destructive” indicates an action that affects media files which the software works with. “Recoverable” files indicate OS level or hardware level things you can do for protection. If I think about teaching, these words help someone to understand what is possible and the implications of their actions, and further, a meaningful model of the various levels at which they are interacting with an NLE and computer. The words lead to understanding, in a way that “destructive timeline” simply doesn’t.
Franz.
-
[Herb Sevush] “Under this definition pretty much anything other than assembly is destructive, at which point the phrase becomes close to meaningless”
Agreed, but this is why scope is important. Not all data has the same value, but the same piece of data may have different values to different people in different situations.
I don’t think we can escape the idea that eventually we have to make a decision on something and eventually we are going to make some point-of-no-return data alterations. With most software, even non-destructive/uncommitted workflows require committing to parametric data at some point and removing the previous instance of parametric data.
Just like in physics, point of reference is important. We can change the volume of a clip in the timeline by keyframing, then change it again. This is non-destructive/uncommitted to the clip, but it is destructive/committed to the volume keyframe curve.
It’s turtles all the way down.
[Herb Sevush] “I think I like this better; an act is destructive when it limits the future options you have in regards to both the media and its representation in the software. Once you’ve added a blur and flattened a layer you no longer have the choice to work with an unblurred image in that object – it doesn’t have to have blurred the original media, but it does have to affect the object you are working on in an irreversible way. A deleted clip can simply be edited back into the timeline, you have that choice. A flattend image cannot become unblurred, no matter what you do. You can create a whole new object using the same media, but that’s not the same thing. I think.”
I get where you’re going, but I think that re-importing the unblurred original image object into your composite is analogous to re-editing a deleted clip object into your timeline.
Walter 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