-
Amazed at render mgmt – and a downside
This app never ceases to amaze me. I already knew that X was pretty amazing at render management. For example, if you render a section, then make a bunch of changes, but then decide to change even just a portion of something back to a previously rendered state, then X will simply return it to rendered. This was absolutely not possible in legacy, nor any other NLE I’ve seen. The only way to return something to a previously rendered state was to hit undo. If for example your rendered a stack of layers, then deleted a layer in the middle, then replaced it with an identical copy from the bin, any other app would require you rerender. But X simply says, “oh, we have a render in the cache that meets that criteria, lets use that.”
So I already knew X could do that. Nice. But recently I had a long version and a short version of essentially the same sequence. Everything had been locked in and approved in the longer version before we began to cut it down to make the short version. But of course a lower 3rd needed to be changed. Instead of changing one and copying and pasting to the other sequence, it was just easier to retype them both. I retyped the first one and rendered. Then I retyped the second one, in a whole separate sequence, and the instant I was done typing, it was rendered! Just because it happened to have media exactly matching that render in the cache already. But not just a match of TC and file names, a match of the actual typed text too. Nice.
And another example. I duplicated an unrendered sequence today to create a new version. I finished the new version and rendered. The first version instantly recognized all the parts that were the same and it was now rendered too in those areas. That’s efficiency. And pretty damn cool.
I think this new behavior (the 2nd two examples) is the result of an efficiency of having projects grouped into libraries. and Render media is associated with the library, not the project as in the past, so render media is shared. Previously if you duplicated a sequence, all the render media had to be duplicated or you could choose not to duplicate the render media. The two versions of projects never shared one single frame of rendered media. They were kept separate just as libraries don’t share render media now.
A downside to this I’ve also discovered, is that X isn’t smart enough when you delete render files. If you say to delete the render files for a sequence, it deletes all the render files for that sequence no questions asked. If those render files are shared by another sequence, then tough shmit. They’re gone too. And duplicating a sequence doesn’t duplicate the render files. In legacy, I do believe that it was smart enough not to delete the render files in a sequence that were also being used by another. But I could be mistaken.
Anyway, another huge benefit of Libraries.
-
14 Replies
-
[Bret Williams] “For example, if you render a section, then make a bunch of changes, but then decide to change even just a portion of something back to a previously rendered state, then X will simply return it to rendered. This was absolutely not possible in legacy, nor any other NLE I’ve seen.”
Because you never used *edit.
Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf -
I have heard that about edit now that you mention it. I’ve used a lot of other NLEs over the past 20 years, but not edit*.
So is there a footnote or something? I was always looking at the bottom of the page to see what the catch was.
-
Avid does it too under most circumstances. If you render a sequence, move stuff around, then move media back to where it was when you rendered the render relinks. FCPX seems to do it under more circumstances, though (removing a lower third and cutting it back in from the original i your bin doesn’t relink to the render file in Avid, and rendering one sequence doesn’t result in a secondary sequence being rendered).
—————-
Michael Hancock
Editor -
[Michael Hancock] “Avid does it too under most circumstances.”
As did Avid DS.
It’s not an NLE, but the render cache in Ae CS6 and up caches footage and rendered effects on a per-layer basis, and matches them back according to source, properties, and effects. If you use the same effects on the same footage in two separate projects, it need only be rendered once.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Bret Williams] “So is there a footnote or something? “
No footnote, it’s just that edit* was way ahead of anything like legacy when it came to rendering. Unlike legacy it intelligently rendered only what had to be rendered to effect actual visual changes to the timeline. And the new renders had their own “track” on top of the timeline.
Mow it’s been 10 years since it was EOL’d but I believe the renders came in layers, and could be deleted to re-reveal old renders underneath. It wasn’t automatic, but if you wanted to restore something in the middle of a long and complex render it only took a moment to accomplish. At least this is the way I remember it. Hopefully another old edit*or can come on and confirm or deny.
Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf -
What I loved about Avid (and it’s been a good 10 years) was DESTRUCTIVE compositing. Destructive compositing is a wonderful thing. FCP always made it out that they had “non-destructive” compositing. Which just meant, it’s gonna take one helluva long time to rerender that, just because you added a bug to the top layer.
In Avid I could render a stack of stuff, and then add a new layer on top, and it used the render file as a single source. You wouldn’t even need to render they new addition because it could certainly play in rt with the lower stack.
Yes, you could continue on in this method rendering each layer as you go and the image got softer and softer. But it’s better than working in some low res mode. And when you’re done, you deleted the render files and rendered it all ONCE as non-destructive.
Destructive compositing would be a welcome addition to FCP X for me.
-
Avid can do this too… only in the far opposite direction: it doesn`t, ever, want to delete those render files. If you `clear renders`they are kept on disk… just not available anymore. If you actually want to delete them you need to use the media tool. End of rant.
-
Ah, one of those. I’m sure it was great, but I was never a fan of that. I used two other systems that did that. The video sphere, which was essentially a multilayered version of the immix video cube. It had all this layering and RT capability, but to render, you had to tell it to compound a section into a clip and then you placed that clip back into the timeline. Usually at the very top of the stack. But it was a manual process. And that render file had no management. It knew not where it came from or how to recreate it or redigitize it, etc. Ridiculous design.
And I used editDV at home when I was a freelance Avid editor because FCP wasn’t out yet, and I could bring home DV copies of my work and make demo reels. I did a few little projects on it, but then FCP 1 came out and I made the switch. But editDV had a render track up at the top. And it was kinda up to the user to mentally keep up with what needed to be rerendered or not. The track, while better that the sphere solution, still knew not where it came from or if changes had been made beneath it. Not a fan of that one either, but it was useable. Hopefully edit* was a bit more advanced.
-
[Herb Sevush] “[Bret Williams] “For example, if you render a section, then make a bunch of changes, but then decide to change even just a portion of something back to a previously rendered state, then X will simply return it to rendered. This was absolutely not possible in legacy, nor any other NLE I’ve seen.””
If I understand well what you are saying, PPro CC works in the same way.
Santiago Martí
http://www.robotrojo.com.ar
Red One M-X, Red Epic X waiting for Dragon update, Red Pro Primes, Adobe CC, Assimilate Scratch -
[Bret Williams] “Hopefully edit* was a bit more advanced.”
edit* started out as D/Vision, which, along with EMC, was the best PC NLE editor in the 90’s. It was re-written for windows and then bought up by Discreet Logic, who wanted it to compete with Avid as an off-line editor to feed into the whole Smoke, Fire on-line system. This was viewed as a great move by D/Vision-for-windows users but was a nightmare, starting with the ill conceived name change to “edit*”. the problem from Discreet’s point of view was that it was too good – it was not only feeding into Smoke, it was, when combined with Combustion, beating the pants off it for a fifth of the price. It was easily the finest NLE I have ever worked with, although primitive by today’s standards, and superior to Avid in almost every way at the time, but not nearly as well known. When Autodesk bought up discreet, edit* became the victim of corporate infanticide, and I eventually moved on to FCP, a move that to this day I think of as a lateral, as opposed to upward, progression.
So yes, I think it was a bit more advanced than editDV.
Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf
Reply to this Discussion! Login or Sign Up