-
FCP7 review by someone who likes FCPX
-
“When Alban posted elsewhere features that he liked that are unique to FCPX, some people brushed them off as not important.”
Since I am that “some people” I think I ought to clarify the context. Scott Sheriff posted the following in response to a question.
“3. I hear that FCPX is missing a lot of features real editors would be loathe to give up.”
You heard right. No tape I/O, no XML, no OMF, no multi-cam, no ability to open legacy projects, no way to share a project with another editor due to file structure, no way to assign tracks. There’s more, but that should give you an idea.”
Alban then responded by listing all the new features of FCPX that he valued. My response was mainly meant to distinguish between essential industry standard functionality and the given properties of an individual program.
Essential industry functions are those things common to all NLEs – if a facility was going out shopping for a new NLE what are the basic features it would have to have. (I’m talking here about a high end facility that has to accommodate various different clients and workflows.) Scott’s list is full of those.
Alban responded by saying in effect “so what, FCPX has all this …” – and listed a bunch of program specific functions – skimmers, smart collections, etc.
I was trying to point out they are not the same. The industry standard functions are used by every major NLE without exception.
In addition each individual NLE has their own program specific functions that give them their individuality and appeal – Avid’s trimmer and media management, PPro’s integration with AE & Photoshop and the mercury playback engine.
Different people will have different opinions of the program specific functions – some may love the skimmer, some may not.
Facilities don’t have opinions about Multi-Cam and OMF export – either you have them, or don’t bother showing up.
My previous post was trying, badly, to say these 2 types of feature sets are not comparable. You can love the auditions in FCPX all you want, but if you can’t monitor properly, no high end facility will use it.
Obviously all this changes when FCPX gets updated, but for now Scott’s original response was correct, and Alban’s was off the mark.
“In the meantime I too make do with “hybrid” workflows but the time savings I get in FCPX on projects that don’t need the missing features are incredible.”
A description of a project and how long it might have taken you before vs taking you now with X would be helpful, and where in the process you think the time savings are happening.(this is a real question, really would like to learn, not baiting you here.)
Herb Sevush
Zebra Productions -
[Jeremy Garchow] “Sorry, I am not trying to start a bad argument or anything, I am just talking about this.”
Jeremy, we’re of the same mind here. I certainly didn’t intent any animosity, and I apologize if you read any from my post.
[Jeremy Garchow] “Yes, it doesn’t align with the wheel, and yes, the theory behind color might get lost on some, but it is still viable. This doesn’t mean that someone couldn’t learn to use that tool and get similar results out of it. So what if they did add yellow instead of minus blue, the intended result is the same “color”. In that sense, they are still using a tool.”
I agree. The color board is functionally no different from the color wheel; the interface is fundamentally the same (a control point on a plot), and there’s absolutely nothing that one of these tools can do that the other can’t. I understand that the color board is more intuitive than the color wheel, as most people don’t have daily experience with polar graphs.
My problem is with the oversimplified, insular thinking behind the color board. Apple decided to revise an industry-standard interface which represents both the intention of the user and the theory that accomplishes it. They replaced it with an interface which represents only the intention of the user, presumably to save the user the trouble of learning how to indicate opposites on a polar graph.
They are separating the user from color theory and from the interface used across toolsets everywhere else in the industry. Why? They didn’t oversimplify the rest of the color tool. Is the color wheel really that much harder to understand than hue, saturation, and luma adjustments across shadows, midtones and highlights with unlimited secondaries?
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 -
[Walter Soyka] “Jeremy, we’re of the same mind here. I certainly didn’t intent any animosity, and I apologize if you read any from my post.”
None at all. I just don’t want to be seen as the guy that jumps on ever thread to make excuses for a controversial launch. I am glad we can have a healthy dialogue. I think it’s important to help all of us understand what’s going on right before our very eyes.
[Walter Soyka] “They replaced it with an interface which represents only the intention of the user, presumably to save the user the trouble of learning how to indicate opposites on a polar graph. “
Could be true, yes. I also think, from a simplicity of design standpoint, the color board fits better in that section better than three color wheels would. It also brings some parity to the other controls as well (saturation and exposure) that couldn’t be done on a color wheel. I think that represents a design choice and we all know how apple loves the interface design. I’m not saying it’s right, just what it is, for better or for worse. If it didnt work, it’d be another story because really, why reinvent the wheel? Hope that was punny enough…
[Walter Soyka] “Is the color wheel really that much harder to understand than hue, saturation, and luma adjustments across shadows, midtones and highlights with unlimited secondaries?”
No, I don’t think so. For someone who isn’t familiar with Color theory though, it is interesting to say “I want to remove some of that yellow from the highlights” and then be able to visualize that in the
color board by dragging the puck down towards yellow, perhaps someone else might drag it up towards blue. What I do miss is the “skin tone line”. On a wheel, I know exactly where that falls. On the board, it’s more “look and see” and therefore inefficient.I wonder what a three plot (or puck as they are called) color wheel would be like? Do you think it would be viable? Also, I am sure someone will come up with a color wheel plug like Colorista or other.
The more I really edit with X, the more it sinks in. I like most of it. I really do. It allows creativity, no kidding.
Jumping from crag to crag, the major gripe I have is native format support. While X makes some of the process easier, it really sucks to have to wrap to .mov all the time. AVC-Intra support is really strange. The lower bandwidth avc-I files take up more room than their optimized ProRes equivalents. This really doesn’t add up for me. A 145mb/sec (ProRes) file should be bigger than a 100mb/sec AVC-I file, but this is not the case.
No native red support. In fact, every camera that doesn’t natively shoot QuickTime still has to go through what I believe to be unnecessary steps to get to editing. Tapeless should be faster, as all the video, audio, and some metadata is right there for the taking.
I was really hoping AVFoundation would alleviate a QuickTime rewrap. Unfortunately on this point, I truly don’t think Apple will change much. I hope that developers/third parties will be able to write in native support without a log and transfer process. More so than the interface, this lack of native digital media support will drive us towards Premiere, where the native format support is incredible. Actually let me rephrase that, it’s where it should be, direct access to the a/v essence of any media file.
-
[Jeremy Garchow].AVC-Intra support is really strange. The lower bandwidth avc-I files take up more room than their optimized ProRes equivalents. This really doesn’t add up for me. A 145mb/sec (ProRes) file should be bigger than a 100mb/sec AVC-I file, but this is not the case.
I can’t say this with any authority yet (kind of new in working with ProRes on any regular basis and waiting to start shooting AVC-I), but I believe that AVC-Intra is a constant bitrate format (i.e. if you are shooting the full AVC-I 100 it will be 100mb/sec constantly), whereas ProRes seems to be a variable bitrate (I’ve noticed that the bitrate seems to change while encoding).
I believe this might explain the difference in size.
-
[Gary Huff] “I believe this might explain the difference in size.”
I understand, I’ve been working with AVC-I for quite a while now.
Yes avc-I is cbr, ProRes is vbr, but the difference in file size is tremendous. It was not this way in fcp7.
I’ll dig up the post I had about this when I am at a real computer and not my phone.
-
Gary, I couldn’t find the thread so I did another test.
After transfer the “original” transcoded AVC-I movie is 240MB. The optimized ProRes movie is 60MB. There is no way the ProRes is 4 times as efficient as AVC-Intra with a higher target data rate, unless there’s some really crazy stuff going on that I don’t know about.
Jeremy
-
As a vacillator who still hasn’t applied X to a professional project I have to say I’m agreeing with you Craig.
I had to crank out a ridiculous deadline last week of 5 TV spots for a last minute presentation. I began thinking how much I wished I was working in X after repeated clip collisions. Going between the two paradigms is definitely helping me see the value of both, but I’m “this” close to pulling the trigger on using X for all our new schedule of work.
Reply to this Discussion! Login or Sign Up