-
Hate and Love
-
[Bret Williams] “No love for hitfilm round here I guess. I haven’t played with the latest, but isn’t it trying to do everything?”
Up until now, trying to do everything within a single app has never seemed to be a winning strategy. Not that you can’t do it, but rather the market moves to one function over others.
Quantel’s eQ/iQ/Pablo/RIO was originally designed as an editor and that is still at the heart of the system. Yet, in the market it evolved into mainly a high-end color correction system. Avid DS (originally Softimage DS) was another system that was trying to be more than an editor. Although it had a lot of fans, there weren’t enough to make financial sense for Avid.
Resolve is trying to become an “everything” system. So far the work BMD has done looks promising and it is free. But we’ll see how many folks seriously take it on as a full-time editor.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Simon Ubsdell] “I’m really not sure. I’m pretty certain that any “one roof” über-application has to be built on the concept of rooms – if I’m grading or doing audio post or visual effects or mograph, I want a dedicated interface and I really, really don’t want to have to be poking around in some fiddly sidebar.”
I think this is not just about the UX/UI, but rather the data model that the application embodies. And wrapping all of post production into a single, cohesive data model that could be contained in “one room” is a significant challenge.
Nuke Studio is a great example of this. An individual shot may be a .nk Nuke script, but an editorial timeline is contained in an .hrox Hiero project document. It’s not just that there’s a compositing room and an editorial room; it’s that these two elements are comprised of completely different stuff with completely different representations under-the-hood.
I think Flame has the most interesting (and mind-bending) design here: a clip is a timeline is a flow graph — but Flame is also the original many-rooms application in post.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
Thanks for your very interesting reply.
[David Lawrence] “A single layer can only hold a single instance of a media object.”
I think my hesitation here would be that this is describing the way things are in, for example, After Effects rather than the way things might be in a parallel universe where Adobe rewrote it from the ground up, which is what I was speculating about. I was wondering if it is genuinely not possible (even theoretically) to have “layers” that held multiple clips in the exact same way that “tracks” do.
Walter would know 😉
Simon Ubsdell
tokyo-uk.com -
[Tim Wilson] “And Herb, do you find yourself able to live in one environment because of the range of your tasks, or because of how extensible your NLE is (whether with native structures, plug-ins, or whatever)? It’s obviously a mix of both, but what’s the dynamic between tasks and tools for you?”
Both. I’m primarily a picture/content editor. I don’t do many promos, or anything else under 5 minutes, and lately nothing under 30 minutes. My current clients want me to finish for broadcast internally – no budget for grading or audio mix sessions. Given that I have to grade, mix and composite myself, but none of these at a very complex level, I’m looking for “high floor, low ceiling” tools that are as compatible with the 90% of the time I’m spending in my NLE as possible – which is why I preferred Motion to AE, and was quite happy with Boris FX back in my edit* days.
I’m not looking to have everything done within the same NLE UI but it would be nice. I’ve grown accustomed to highly integrated round tripping between task specific UI’s – does it really matter to me whether or not Audition is a “room” within Ppro or an integrated third party ap ? – to me it doesn’t.
Every CG in every NLE I’ve worked with had a totally alien UI to the host, but as long as I could compose my titles with reference to a specific video background specified by the timeline I’m working with, it doesn’t matter to me if the CG is considered “part of” the NLE or “third party.”
I don’t want to have to open and close third party programs, nor do I want to have to manually import assets into a third party ap that I’m already working on within my NLE. This was part of my concern with FCPX – no round-tripping to Motion, video capture from tape strictly using third party aps. While the latter concern is a thing of the past, I don’t like the approach.
So to answer – ideally I would like to have all aspects of my work under one roof, but not at the cost of having inferior tools to work with. Pragmatically, round tripping is a form of unified “roof” and at the moment Ppro supplies the best version of it that I’m aware of.
Herb Sevush
Zebra Productions
—————————
nothin’ attached to nothin’
“Deciding the spine is the process of editing” F. Bieberkopf -
[Simon Ubsdell] “Walter would know ;-)”
“Know” might be a bit strong. But “theorize,” absolutely!
[Simon Ubsdell] “I think my hesitation here would be that this is describing the way things are in, for example, After Effects rather than the way things might be in a parallel universe where Adobe rewrote it from the ground up, which is what I was speculating about. I was wondering if it is genuinely not possible (even theoretically) to have “layers” that held multiple clips in the exact same way that “tracks” do.”
At first blush, I’d say that an Ae layer is the conflation of a clip and a track. Like squares and rectangles, a layer cannot do anything that a track can’t do, but tracks can do things that layers cannot.
In parallel-universe-Ae terms, no problem. I don’t see any logical reason why you couldn’t build a track-based (or trackless/non-layer) compositor. With an imaginative UI, it could be a really interesting solution to one of the biggest challenges I see in motion design today: where editorial ends and design begins.
In this-universe-Ae terms, there’s a lot more to it than that.
For every single property of a layer, you’d have to decide if it applies to clips, tracks, or both. For every layer property you assign to a clip, you must change the UI. For every layer property you assign to a track, you must change the render pipeline.
Then you must think about the new things you can do with tracks that you couldn’t do with layers, and figure out what new capabilities you will implement. Cut points become implied objects, so you could have transitions (a concept which does not really exist in layer-based Ae). The track may or may not be treated as an effects bus, and that decision is but the first domino in a new set of capabilities and limitations.
There are few tricky UI considerations. Ae hotkeys are generally modeless, and there are no good ones left for editorial control. Control of properties outside of the clip extents in a tracked system would be tricky because they’d collide with other clips on the same layer. Allowing more than one clip per track/layer means that you’ll have to navigate both horizontally and vertically to find a clip.
Unless “tracks” were just a condensed, quasi-read-only view derived from the real layer timeline, you’d also be drastically changing the data model. That has big implications on the enormous third-party ecosystem Ae has. If the new data model were not backwards-compatible, any script or plugin which traverses the comp structure would be broken.
I’d suggest this is the most important point in this post to the larger discussion we’re having here. The data model is the core of an application and it defines the limits of an application’s extensibility.
That core also requires the most effort to change because it has so many dependencies, both internal and external. Any development decision deserves some cost/benefit analysis, and the cost is automatically exponentially higher for core data model changes.
Walter Soyka
Designer & Mad Scientist at Keen Live [link]
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
@keenlive | RenderBreak [blog] | Profile [LinkedIn] -
Great answer, Walter, thank you!
I guess I was thinking more about the alternative universe and what one might like a “track-layer” to look like, rather than the more obviously impractical in this universe task of converting Ae to work in “track-layers”. The reason I brought this up was in answer to David’s point that it couldn’t be done – obviously he’s right that there are insurmountable obstacles to doing it with the application we know as After Effects, as you’ve explained so well, but to what extent is it theoretically impossible/impractical?
[Walter Soyka] “The data model is the core of an application and it defines the limits of an application’s extensibility.”
Yes, this is clearly an important insight – all too easily overlooked in discussions about how we’d like our applications to evolve.
Simon Ubsdell
tokyo-uk.com -
[Simon Ubsdell] “but to what extent is it theoretically impossible/impractical?”
I would say that transitions pose a special challenge — they require some in-track compositing that could break the rest of the render pipeline. How do you handle the alpha in a transition between two non-output-sized objects? How do you handle a transition between a 2D and a 3D object?
With that out of the way, I don’t see any reason why it would be theoretically impossible. I can’t think of a single thing that you can do in terms of a render pipeline with layers that you can’t do with tracks.
Your challenge: what’s impractical about tracks (or trackless multi-object containers) versus layers from a compositing standpoint? My answer: the quick description I gave of Ae-specific challenges can be generalized. Like David and Tim said, compositing tends toward the vertical while editing tends toward the horizontal.
To flatten layers into clips in containers, you must hide layer-based information in the clips, obscuring important compositing information. To expand clips in containers into layers, you must separate joined objects and consume extra space, obscuring important edit information. (Maybe there’s a lesson to be learned from FCPX’s notion of primary content?)
While I think that editing and compositing can be contained within the same data structure, I think that those opposing ideals suggest that a single UX around that data that’s meaningful for both tasks at the same time is not the best solution.
I think that an interesting possibility would be to try not to serve two masters with the same view, but rather to give two or more different windows into the same pool of data. How about keeping layers, and adding a (possibly non-magnetic) trackless editorial timeline? Imagine a filtered, automatically-collapsing vertical stack that is an editorial view of the real layer-based timeline. This would enable timing changes but not compositing changes. Just switch back to full layers for compositing changes.
There’s still plenty of room for UX evolution in compositing! Consider Mistika.
Maybe a timeline doesn’t have to be a timeline. A look at Mistika’s timespace construct could be informative. It’s a bit like what you’d get if you took absolute time from Premiere, tracklessness (but not magnetism) from FCPX, and on-timeline effects stacking from Motion, and then smushed them all together.
Mistika allows you to composite with both layers and nodes. See 0:58 at the video below. It’s gone in a flash, but you can see a node graph side-by-side with a timespace. The addition of “links” (kind of like Motion’s clone layers) in the timespace allows the same comp to be represented and manipulated in either/both the node graph and in the the timespace.
https://www.youtube.com/watch?v=Zj3w9dGw6II
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 would say that transitions pose a special challenge — they require some in-track compositing that could break the rest of the render pipeline. How do you handle the alpha in a transition between two non-output-sized objects?”
Simon, et al – Walter and I got deep into this issue in this thread in the After Effect forum:
https://forums.creativecow.net/readpost/2/1067127
As I learned in this thread, transitions that are trivial in an NLE present special challenges in a compositor. This becomes interesting in the context of round tripping between applications. In my case it was via Adobe dynamic linking. Dynamic linking is great, but I was surprised by the transition problem. It’s important to understand that some things don’t exactly translate. Now that I know how it works, in the future I’ll set up my Premiere transitions differently if I plan to go into AE.
_______________________
David Lawrence
art~media~design~researchlinkedIn: https://lnkd.in/Cfz92F
vimeo: vimeo.com/album/2271696
web: propaganda.com
facebook: /dlawrence
twitter: @dhl -
This UX and objects conversation is interesting, but it seems a bit esoteric, even for me 😉
Isn’t one of the core differences between an editing app and a compositing app the way in which media playback is handled? In general, a compositor is designed to move frame-based media into an uncompressed RGB 4:4:4 progressive buffer, regardless of the original codec. This is difficult to do in real-time. OTOH, an NLE is designed to deal with movie streams, usually in a native or compatible codec. An NLE is often dependent on an underlying media engine to handle part of the actual movie file playback, a la QT and FCP7. As a result, real-time playback is easier, but compositing might not be quite as good.
Some NLEs and/or compositors achieve both aims. Quantel and Flame come to mind. In past years, I’d also lump products like Media 100 844/X and DFX Composium (a linear system) also into this category.
IOW, regardless of the interface design, there are still real-world engineering differences under-the-hood. What do you think?
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Oliver Peters] “In general, a compositor is designed to move frame-based media into an uncompressed RGB 4:4:4 progressive buffer, regardless of the original codec. This is difficult to do in real-time. OTOH, an NLE is designed to deal with movie streams, usually in a native or compatible codec. An NLE is often dependent on an underlying media engine to handle part of the actual movie file playback, a la QT and FCP7. As a result, real-time playback is easier, but compositing might not be quite as good.”
Yes. Thank you for more precisely articulating what I meant by this:
[David Lawrence] “Compositors by design prioritize calculating the correct value for every pixel of the frame, based on the media and processing pipeline in the composite stack. NLE do this too, but by design, playback seems to be the first priority.”
[Oliver Peters] “IOW, regardless of the interface design, there are still real-world engineering differences under-the-hood. What do you think?”
Absolutely. I think that’s why we see various different data models and UI approaches to working with time-based media.
_______________________
David Lawrence
art~media~design~researchlinkedIn: https://lnkd.in/Cfz92F
vimeo: vimeo.com/album/2271696
web: propaganda.com
facebook: /dlawrence
twitter: @dhl
Reply to this Discussion! Login or Sign Up