[Andrew Richards]

[Franz Bieberkopf] “Also, and correct me if I’m wrong, I assume you’re casting Apple as an ‘outsider’, posed rebelliously against ‘elites’. Am I correct?”

I read it as the outsider user, not the outsider software developer. For legacy FCP, this pattern was true. The high-end elite didn’t hop on board till after Soderbergh and Murch took the plunge, and even Soderbergh and Murch only did it a few years and a few major revs after FCP1 came out.

Best,
Andy

[Andrew Richards]

[David Lawrence] “I think there’s more going on than just muscle memory habits. A good UI makes the expression of user intent natural and intuitive. My current experience with X is that it often confounds my natural rather than learned expectations in terms of both spatial and object behavior. If a UI is intuitive, changing to it should be easy because it makes intuitive sense. IMHO, the fact that so many experienced editors are having difficulty is a clue that something is off. I’ll get into this more in my next post.”

I forget who had it in their post or signature, but the quote jumped out at me; “The only ‘intuitive’ interface is the nipple. After that it’s all learned.”

I’ll argue your intuition is strongly informed by your decades of experience. Intuitiveness in software is all about familiar analogs, since all software UIs are metaphor. If FCPX is unintuitive to an experienced editor, but intuitive to the uninitiated, that just means FCPX was successfully designed to make sense to the uninitiated. I totally understand how this is a turn-off to experienced editors, but intuitiveness isn’t an absolute, it’s relative to the user’s experience.

From another of your posts in this thread which dovetails:

[David Lawrence] “This is a very important point. FCPX’s default behaviors amount to editorial decisions. When the software automatically resolves a conflict, it’s making default assumptions about my editorial intent. Short of reading my mind, I don’t see how it can ever get this right more often than not.”

I could argue that FCP7’s default overwrite behavior also amounts to editorial decisions. We’d both be right- both apps have a default behavior the editor needs to be aware of. Both default behaviors can result in some sort of adjustment being necessary to resolve what the editor intended to do in an edit. The only difference I can see is that one default behavior has been around a lot longer, and a lot of editors are used to it and expect it. To play devil’s advocate for FCPX’s default behavior, isn’t a non-destructive default favorable to a destructive one? (by “destructive” I mean to the existing structure of the timeline, not to anything else)

[David Lawrence] “Clip collisions, etc. are just not a problem for me. No doubt because I’ve internalized TTT and moving things around. But even when I do encounter a collision, conflict or media limit, I consider that an editorial problem. The software can only guess at my intention and it’s as likely to guess wrong as it is to get it right. There comes a point where it’s more efficient to just let me handle it.”

If it is only as likely to guess wrong as it is to get it right, with either default behavior you have to handle something about half the time. In FCPX that might more often be removing more content around an edit. In FCP7 it might more often be adding it back. Again, the only difference is that you are accustomed to the latter and not the former. Naturally, you’ll be more comfortable with the familiar. Wait till you install Lion and try to scroll with a trackpad!

None of this is to suggest you or Herb or anyone else is wrong to prefer the way FCP7 behaves to the way FCPX behaves, but I don’t think there is any fundamental problem with FCPX’s UI in this regard.

Best,
Andy

[Andrew Richards]

Jeremy laid it out better than I would have. I yield the floor.

Best,
Andy

[Andrew Richards]

[Chris Walsh] “They also mention any intriguing structure called a “Track” in the AVAsset class:

“Each of the individual pieces of media data in the asset is of a uniform type and called a TRACK. In a typical simple case, one TRACK represents the audio component, and another represents the video component; in a complex composition, however, there may be multiple overlapping TRACKS of audio and video. Assets may also have metadata.”

I really like this “track” idea.”

Be careful you don’t conflate AVAsset tracks with respect to components of a media file with how a certain NLE’s UI is designed to represent the manipulation of those tracks in a timeline… 😉

Best,
Andy

[Andrew Richards]

[Timothy Payton] “Just curious, I hear all this talk about av foundation. However, on the apple dev site, it states that av foundation is part of iOS, while core media, core audio, core video, etc. is for Mac OS X. Is the dev site incorrect?”

It is out of date, as of yesterday. Lion adds AVFoundation to OS X. The Dev sites will be out of date for several days while Apple updates them. AVFoundation is a superset of CoreMedia, CoreVideo, CoreAudio, and CoreAnimation. It allows developers to write less code if they are tacking common media handling tasks like dealing with MOV files. The lower level CoreMedia, CoreVideo, CoreAudio, and CoreAnimation APIs are there for doing things at a more granular level of control that AVFoundation might offer.

Best,
Andy

[Andrew Richards]

Never jump on a new major OS rev at .0 for critical workstations, but there are lots of good things in the guts of Lion that Apple doesn’t trumpet because they don’t appeal to curious iPad owners that might be considering their first Mac. Apple may not focus on the tech roots in there marketing, but Lion is one of, if not the most significant updates to OS X’s underpinnings in some time. It is a long read, but John Siracusa’s exhaustive review at Ars Technica gets into it all.

Best,
Andy

[Andrew Richards]

[David Lawrence] “Linear time scale is not the issue, it’s about frame-of-reference in regards to spatial representation and object/space behavior. I think it’s a pretty big deal in terms of UI design change.”

I completely agree with that, but that isn’t what I understood your opening post to be about. This is the bit I’m referring to:

[David Lawrence] “This is where things get curious with FCPX. FCPX has changed the master clock.

FCPX changes the frame-of-reference for the master clock from what we’ve used for decades — the sequence window, a fixed, external frame-of-reference defined by absolute spatial position — to a container object inside the sequence window.

In FCPX the primary storyline is the master clock.

This is why there can only be one primary storyline. This is why connected clips only connect to the primary storyline. In object-speak, the primary storyline is the parent container for all media events in the sequence (project).

This change in itself is a big deal. It means that in FCPX, we edit the temporal frame-of-reference as we edit our piece.

And it gets more complex because FCPX’s master clock has gravity. Locked in ripple mode, the primary storyline always pulls all contained objects to the singularity of 00:00:00:00. This is useful if you need help avoiding black gaps in your program, but it has a side effect of constantly changing the time position of everything else you’re working on. This may or may not be a problem depending on what you’re doing.”

My initial understanding of your argument from that excerpt was that the media in the Primary Storyline is the base manifestation of time scale in the FCPX timeline.

I disagree.

The timeline is the master clock, just like it is in FCP7. In FCPX, you create a Project and set its frame rate. In FCP7, you do the same thing with a Sequence. Both offer the option to match the frame rate of the first clip added to their respective timelines. Before any media is added, before any Primary Storyline is created, the FCPX timeline has a “Master Clock”, to borrow your terminology.

The big change, IMHO, isn’t that time is rooted somewhere new. The big change is, as you put it, is with “spatial representation and object/space behavior”. This absolutely forces the user to adopt new habits for constructing an edit, but the way time is framed hasn’t changed, just the way it is filled with content.

Granted, a ripple edit, which is the default behavior for the magnetic timeline, will alter where on the timeline subsequent media sits, but this is true in traditional timelines as well. It just isn’t the default. FCPX has a Position tool for making adjustments to the timeline without incurring a ripple, just like FCP7 has a Ripple tool to do the opposite. The default behaviors differ, but the way time is metered does not.

I get the sense your main objection to FCPX’s default timeline behavior is that when you are editing, you do not want to ripple the edit because this ruins direct clip-to-timline spatial relationships you already placed further down the timeline.

I now understand your “master clock” to be not the time scale set for the timeline, but rather the spatial relationships of the clips relative to the timeline. I understand why the shift from placing disconnected objects in what is essentially a grid (traditional timeline) to stringing together explicitly connected objects (magnetic timeline) is significant, but my take on it is that any UI metaphor forces the user to adopt interaction habits based on the UI’s behavior. The UI metaphor you helped invent has been used for decades by every major NLE since, so it is a powerful convention.

Breaking decades old habits and muscle memory is a shock to any user, and I think that’s a huge reason why so many veteran editors recoil from the way default behavior of FCPX’s timeline. I was certainly very disoriented the first time I sat down at FCPX in February at SFO waiting for my flight back from the now infamous “jaw dropping” private briefing. I didn’t know what to make of it, but I they gave us tutorials to follow and I plowed through them trying to keep an open mind.

All things considered, I now like the new timeline. It needs some tweaks, well documented around here, like Precision Editor support in Secondary Storylines, persistent two-up Viewer any time Precision Editor is engaged, more consistent transition behavior, and the already-announced audio output mapping. But I love the potential in it, and honestly I feel I spent a lot of energy manually accounting for collisions in legacy FCP, and I won’t have to think about that in FCPX.

I can also appreciate how others might hate the new way even after giving it a fair shake, so to each his own on that one.

Best,
Andy

[Andrew Richards]

I previously speculated Lion might offer a way to deliver broadcast monitoring to FCPX via its now public AVFoundation APIs (the same set of APIs FCPX is built upon). It looks like that is not the case, and that Apple will need to open some kind of hooks into FCPX to enable real broadcast monitoring. Note that FCPX doesn’t yet offer full screen support in Lion, which is almost certainly a design consideration of the new UI. FCPX 10.0.1 will need to come out to unlock that goodie, so maybe the XML API (and other APIs?) that Apple promised a few weeks ago in their FAQ will come on that update as well. The timing seems about right (“in the next few weeks”).

[Mark Dobson] “Core Media is the new exciting way video hardware devices capture and playback to software applications and it’s the future of video API’s on the Mac OS X platform. Blackmagic Design is the first company to support this new standard, right from the very first day it’s available to customers. Now all developers can design modern 64 bit video software and get high performance capture and playback to hardware, while having the benefit of high quality broadcast solutions for video with new Core Media technology. “

I guess Apple went to the trouble of baking all that CoreMedia goodness into OS X for soccer moms and hobbyists… (sarcasm not directed at you, but rather at the angry mob insisting Apple doesn’t care about creative pros)

Best,
Andy

[Andrew Richards]

[marcus lyall] “A colleague of mine who writes avideo app for mac told me how shafted he felt when qt x came out. Completely crap for dev work. Buggy as anything. Still doesn’t work properly…”/I>

QuickTime X, which is really just the player app written on QTKit, wasn’t a fully-realized replacement for the old QuickTIme APIs. Apple seems to have abandoned development of QTKit and has moved on to AVFoundation, which is the 64 bit successor to the old QuickTime APIs and is only a public OS X API starting with Lion (though it did first appear on iOS in iOS 3).

FCPX is built on AVFoundation, and Apple wants developers dealing with time-based media to call upon AVFoundation for all relevant work moving forward. The earliest anyone would have been able to start coding in earnest with AVFoundation would realistically be only the last couple months, unless some enterprising coders dug into it in the Lion betas prior to WWDC11.

The QuickTime brand is just that now, a brand. The old 32 bit QuickTime frameworks are still there in Lion, but they have been deprecated for some time (at the very least with 10.6 and possibly as far back as 10.5, can’t recall), and AVFoundation is the way forward for any developer dealing with time-based media in OS X moving forward.

Best,
Andy

[Andrew Richards]

Select the clip(s) and then in Speed Controls and select “Conform Speed”. This has the same effect of conforming in Cinema Tools, but is non-destructive.

Best,
Andy