David Lawrence
2
COW Coins
Forum Replies Created
-
[Andy Neil] “And conveniently dismissing compound clip behavior because it “should’ve been there” is just you creating a confirmation bias. It wasn’t there before. It wasn’t designed that way before. It was changed in 10.0.06 and it fundamentally changes how one edits in FCPX.”
Compound clips were fatally flawed before 10.0.6. The design was broken. This is a bug fix, not a feature.
[Andy Neil] “Perhaps you meant to only comment on the modality of the timeline, I don’t know. But you said “editorial model” in your OP and to me, that’s anything that changes significantly how someone can edit in an NLE. Like it or not, these additions, including multicam have done just that for FCPX. I agree that it’s unlikely that X will ever have track editing like you’re used to in legacy or Avid, but that doesn’t negate the possibility that Apple will make real changes to the editorial model that we all got in 10.0.0, since it’s obvious that they already have.”
I consider 10.0.0 a poor benchmark for Apple’s progress. 10.0.0 was an alpha-quality mess, likely released because of scheduling and marketing pressures. Certainly not because it was ready. As far as I’m concerned, 10.0.3 represents the first true working version of the program. Multicam, and roles were all in by then.
It sounds like we define “editorial model” in an NLE differently. For me, how the timeline behaves and how it dictates editorial operations is the core of the editorial experience. The timeline is the center, everything else revolves around it.
All the improvements you mention are significant. They added features, but none of them changed the basic operation of the timeline itself. Yes, we’ll see further improvements down the road, but I doubt the core model changes.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Walter Soyka] “In a group, the related clips are peers. In a hierarchy, the related clips are ordered. Different degrees of structure.”
Yes, but from a purely practical standpoint, what difference does it make to playback?
[Walter Soyka] “Maybe here’s a case where a single point (not a range!) is important. Groups do not codify the connection point that defines the relationship.”
True, but again as long as the clips are locked together temporally, what difference does it make? Syncing to a hit point between source and record is a specific edit type (sync/replace edit in FCP7 IIRC) that isn’t used most of the time.
[Walter Soyka] “Here, you’ve conceded that the magnetic timeline has some benefits. What are they, and where do they come from, if not from hierarchy?”
Well, some people think they’re benefits 😉 Isn’t the main one being able to move groups of clips around and reorder things without worrying about clip collisions? I don’t think you need hierarchy to do that, you just need smarter groups and smarter grouping/moving tools.
[Walter Soyka] “the places where I see hierarchy in my work are lower-thirds that are legitimately tiered under speaker clips, graphical elements that are related to specific pieces of content, and sfx that belong to specific moments or graphical hits. “
Great example. In terms of the composite, yes, the lower thirds/graphics could be considered children of the parent content. But in terms of playback, hierarchy is irrelevant. All that matters is that they appear when they’re supposed to in time.
[Walter Soyka] “Is remapping the story structure in the face of a changing edit really any different than remapping nodes in the face of a changing composite?”
Yes, very! A nodal compositor maps the render pipeline for the shot. Remapping nodes has nothing to do with time. Very different tools for very different purposes.
[Walter Soyka] “Let me flip the question around a bit: does hierarchy misrepresent the edit in all cases?”
It’s not that it misrepresents the edit, it’s that in the context of a timeline, it’s an inappropriate contrivance.
The parent/child hierarchical metaphor that drives the magnetic timeline UI is a computer science metaphor, not an editorial metaphor. Maybe it’s an elegant representation of the underlying timeline data model, but the data model is irrelevant to the task of editing. I’ve yet to meet an experienced editor who explicitly thinks in terms of building hierarchies when doing the actual work of cutting. Do you know any?
Designing a UI around a data model may make sense to computer engineers, but it’s rarely good for users.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Charlie Austin] “The who what? got a link to this method? Seriously, I’m interested. :-)”
Here you go:
https://forums.creativecow.net/readpost/335/29301
I think Jim made a template project available if you want to try it out.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Charlie Austin] “The way i use it, that’s exactly how it works. Primary Storyline contains a chunk of gap the length of the spot/trailer/whatever. (actually usually longer so I can store random bits at the end.) Everything is connected to that “time track”. If I want canned transitions or want to use trim mode I make secondary storylines with whatever clips I choose. I can put all my “timeline markers” on the gap. And I can drag stuff around free form just like I’m used to doing but using all the magnetic goodness that X provides. FCPX is ridiculously flexible, contrary to popular misconceptions. :-)”
No doubt you’re using it exactly as the designers intended. 😉 I’d say the fact that you’re using it that way proves my point. But hey, if it works for you and you like it, enjoy! 🙂
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Walter Soyka] “Sometimes, clip are intended to be intercut relative to other clips. The real structure of an edit like this is hierarchical;”
How so? The relationship between clips on a timeline is always temporal. Locking a fixed temporal relationship between clips doesn’t require hierarchy, it requires grouping.
[Walter Soyka] “we just can’t express that on an open timeline (unless we are using Sony Vegas with its sync link feature [link]).”
When I group clips in Pr, how is this not expressing/preserving the desired clip sync relationship? Isn’t that all that matters? Vegas has some nice tools for manipulating individual clips in groups but I don’t find its parent/child paradigm very useful.
I think all that matters is a simple way to make groups and when desired, a simple way to move individual clips without breaking the group. I think this could be done with better grouping tools and would give track-based NLEs most of the advantages of the magnetic timeline without the drawbacks.
I agree with Aindreas, hierarchy is meaningless in an editorial timeline. But if we buy into the FCPX paradigm of parent/child relationships defining the edit, the problem with the FCPX timeline isn’t hierarchy itself, it’s that Apple engineers got the top level parent wrong. The top level parent needs to be absolute, external time; not V1.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Walter Soyka] “So why use an IOP instead of a marker?”
Because an IOP is special. It tells the NLE to act on the marked point.
[Walter Soyka] “Defining a range prepares you for the next operation, whatever it is. “
Sure, but so does marking a single point.
[Walter Soyka] “In a three-point edit, the range of the one-point clip is defined by the duration of the two-point clip. “
Yes, but in FCPX, there’s no way to define a persistent one-point mark. It’s especially bad on the timeline itself. The one-point mark is held by the skimmer or the playhead position. It could’t be more fragile.
[Walter Soyka] “FCPX handles three-point edits perfectly well. “
No argument here.
[Walter Soyka] “I am still not really following. This makes two classes of operative ranges in FCPX. I think a command to recall the last (ghosted but visible) range — or even allow its re-selection with a mouse click — preserves the existing selection model without adding too much more complexity. “
The problem with this is you’re allowed multiple range selections per clip. Which one gets recalled?
[Walter Soyka] “How would you define the problem that your proposed solution sets out to solve?”
I think the problem is defined by the language of editing. When editors say “Mark in” or “Mark out” they’re referring to a very specific thing — selecting an exact point in time. Holding that point for an action now or later. A point is not a range and while range may be implicit, all that matters when we say “Mark in” or “Mark out” is often that single point.
I think FCPX needs a better mechanism to hold these single points that tell the system to “act here”. Right now, they’re either way too fragile (skimmer or playhead) or mixed in with range selection, which has led to the PIOP mess. I think an optional UI overlay/command set for these special, persistent markers would solve the problem. It would need to be properly thought out and designed, but I think it would work.
I don’t mind it being in a different class because “Mark in” or “Mark out” is different than range selection. I imagine it could be easier to understand and would be helpful to many editors who like myself, feel range selection alone is an oversimplification of the standard editorial toolset.
BTW, it’s not that range selection as the sole editorial UI excludes possibilities, it’s that it’s just another thing that makes the interface annoying to many editors who might otherwise give FCPX a chance.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Andy Neil] “That’s not true at all. Even discounting multi-cam because “it was in development before”, the Event Viewer, Roles, and Audio Component Editing are all major changes to the editorial model of FCPX. You can even make a strong case for compound clip behavior in 10.0.6.”
I get what you’re saying but I disagree. The change in compound clip behavior addressed a crippling implementation flaw and should have been in place at launch. The other changes are welcome improvements but none fundamentally change the editorial model because none fundamentally change the timeline model. It is what it is. I’d love to be wrong but I don’t see it changing that much.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Oliver Peters] “The point is that the core operation inside the application was in place from the start and so I believe the same is true for X at this point.”
Agreed. None of the updates to date have changed the basic editorial model and there’s no reason believe future ones will. Significant updates like multi-cam, were in development from the beginning and would have been included at launch if they were ready at the time. That’s not to say there isn’t room for future improvement with the current UI, it can and will get better. But the basic editorial mechanics seem pretty firmly in place.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Walter Soyka] “Let’s talk about IOPs and ranges. IOPs mark the extents of a range; a range is the sequential set of frames between IOPs. IOPs imply ranges, and ranges are defined by IOPs. “
Yes and no. It’s true that IOPs imply range, and ranges are defined by IOPs. But remember, In and Out marks don’t have to be used together. We’re talking about In and/OR Outs. Editors commonly use In and/or Out marks separately, simply as markers with no intention of setting a range.
[Walter Soyka] “So I’m not sure there are any operations in any NLE that work fundamentally on IOPs and not ranges; every operation I can think of conflates the two. When you cut a source clip into a sequence, you are copying that span of frames defined by the extents. “
Yes, but in a three-point edit, only one side of the edit is a range. The other is marked. The marked side doesn’t care about extents. It’s irrelevant. The editor needs to be able to mark this transition point and shouldn’t be forced to use a range selection tool to do it.
Plus, who says marking an In and/or Out necessarily leads to an edit? It may just be a temporary reminder. It doesn’t rise to the importance of Favorites and it’s not a range.
[Walter Soyka] “this is all a long way of saying that I think the difference between a range and a set of IOPs is insignificant. “
I guess we disagree on this 😉 I think marking a transition point and selecting a range are totally different editorial intentions. Forcing them into the same selection UI was a mistake. The PIOPs mess doesn’t mean that PIOPs are a bad idea, I think it means the current PIOPs implementation is bad design.
[Walter Soyka] “In FCPX, IOPs/ranges are equally useful for organization and editorial. That may mean that setting IOPs/defining ranges may be overloaded, but I don’t think the solution is to use different commands for defining ranges for organization use or for editorial use — that strikes me as too confusing and/or inflexible. I’d be very interested to hear more about how you think separating ranges and IOPs would work, because I’m having a hard time visualizing it.”
[Walter Soyka] “Basically, I want FCPX to be able to recall the last defined range on every clip, whether it was favorited or not — but I don’t want that range to have the same standing with any tool, organizational or editorial, as a properly favorited range. I want it to be a ghost range, which will persist until manually cleared or superseded by a newly defined range, but with only one possible operation: promotion to a regular range (selection).”
What I imagine is a special type of markers, accessible from the keyboard, which would behave much as you describe above. When set by the editor, they persist and take priority over other selections until cleared. They can be used separately or together. If used together to define a range, only one pair is allowed per visible clip instance. They have a different graphic UI so they’re visually distinct. They appear in list view. Their use is totally optional. If you don’t use them, everything works as before 10.0.6. I think making them distinct and separate from the range selection UI is the key to making them work and would be a much simpler to understand solution than the SIOPs concept (which is quite interesting, btw).
[Walter Soyka] “The more I think about it, the more I’m surprised by the Apple 10.0.6 PIOP implementation. Of all the features to bow to pressure on, why did they pick this? Or did they really think that this implementation is an improvement?”
I guess I would ask – why do you think there was so much pressure that Apple felt they had to do this? What does that say about editorial workflow? Hint – it’s not unwillingness to adapt.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl -
[Walter Soyka] “Since we apparently have to be very careful what we wish for, now I want SIOPs instead of PIOPs, so FCPX doesn’t lose user data by design, but also so that FCPX ranges still work as originally intended.”
Walter, I got into this a bit with Jeremy in another thread and was wondering about your opinion. I would argue that selecting ranges and marking In (and/or) Outs are very different editorial intentions. I believe oversimplifying/overloading the range selection UI is the reason so many users clamored for PIOPs in the first place, and why PIOPs are now a mess.
Rather than try to add force a range selection UI to have marker-like functions, wouldn’t it be easier to design a special flavor of markers specifically for In (and/or) Out points? Folks who just want to use the range tool could ignore them. Folks who like marking Ins/Outs would have them as an additional tool. I see no reason why it couldn’t be implemented in a way that works for everyone.
_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl