Andrew Richards
Forum Replies Created
-
That’s just it. The decision to suddenly EOL FCP7 in the face of a big change was the PR disaster that didn’t need to be. Any seasoned Apple observer would have expected Apple to handle such a big change with the kind of finesse we saw with OS 9 to OS X, with PPC to Intel, even with iMovie HD to iMovie ’08. The outcry was “I can’t do my work on X, it simply lacks the features I need”. The missing features were the source of the rage. Apple knew it was leaving a hole in its product and did nothing to ramp their user base to their Next Big Thing. They had always shepherded their users in the past. It was a shock that they didn’t do it this time.
Perhaps they ultimately regretted their handling of the iMovie shift and didn’t want to repeat it. Maybe they foresaw leaving FCP7 out there as a tacit admission the FCPX wasnt worth trying. We don’t know. Perhaps this time next year all this sturm und drang will seem silly in the face of an FCPX that has rapidly matured and is being embraced much more than today. Or maybe Apple burned too many bridges and will assume the sort of reputation that Premiere has been struggling mightily to shed the past five years. I’m rooting for the former, but I wouldn’t bet more than a beer on it.
Best,
Andy -
I’ll agree that the band-aid explanation is certainly a plausible characterization of Apple’s intent, but I don’t think it constitutes praise for how the transition was handled. Have you heard anyone opining that Apple did this the right way? That they didn’t screw up by pulling off the band-aid?
Best,
Andy -
[Herb Sevush] “Didn’t they face something like this when they moved from OS9 to OSX?”
Yeah, you’d think they would know how to handle a transition smoothly…
I don’t think there is any disagreement anywhere that they really botched that aspect.
Best,
Andy -
[Bill Davis] “Don’t know about the dependability of the Apple Insider sources – but I bet it’s going to make a lot of folks here really, really grumpy if this is ever confirmed.”
AppleInsider has a pretty spotty record. On one hand, they pretty much nailed the FCP rumors leading up to X (looking a lot like iMovie). On the other hand, they said Apple was going to kill the Mac mini. Besides, if this is the article you are referring to, they are just quoting Arrington’s comments from the now infamous video (now pulled) that fcp.co and Cult of Mac posted a few days ago.
This kind of thing can’t be confirmed, because it would take someone from the Pro Apps team like Richard Townhill or Steve Bayes or Pete Steinauer or whoever breaking ranks and airing that kind of dirty laundry. Not gonna happen unless one of those guys wants an easy exit from Apple.
I still like Philip Hodgetts’ hypothesis, that FCP7 was going to be the 64-bit FCP, but that had to be scrapped when Apple did a 180 on 64-bit Carbon back in 2007 prior to releasing Leopard. So FCP7 lost who-knows-what features that would have been in early development and the Pro Apps team were forced to look at rewriting everything from scratch. That also neatly explains the relatively thin new feature list of FCP7. If that is all true, one could reasonably picture a juicy morsel like “Apple had a 64-bit FCP and had to kill it” making its way through the game of telephone to become “Apple had a 64-bit FCP8 and decided to kill it”.
Best,
Andy -
[Chris Harlan] “In some cases, you can actually end up with more promo material–in terms of aggragate length–than the source material, itself. Every once in a while it doubles.”
You’re right, I pictured short promos, even several per show, being a small percentage of the show. Not the other way around.
[Chris Harlan] “Now, in FCP 7 when I make six copies of a :30 timeline to change out VO and end plates (Next, Next Thursday, Tonight, etc.) only the changes require additional drive space, as everything indexes back to renders they all share. Is this the case in X?”
When you duplicate a timeline in X, you are given the choice of copying the render files. I think if you do not copy them, they need to be rendered again anyway. As far as I know each timeline in X points to its own private render cache.
On the other hand, if only the plates and VO differ, you could have one timeline in X with all the diffs laid in and assigned subroles that you could toggle on and off for different exports. Might be more than you want to fiddle with though.
[Chris Harlan] “Does that still seem true to you? I really don’t understand the under-workings of X’s event/render/project file, but if I’ve read this thread correctly, It seems to me I’m building a lot of baggage.”
Not if your promo payload is > 100% of the source material. I was figuring on no more than 4-5 minutes of aggregate promo off any given 22 or 44 episode.
[Chris Harlan] “Well, that’s a pretty big “duh,” but I guess you never know who you are talking too. I’m eSata RAID off of my eight core, which does just fine for my current needs.”
Didn’t know your rig. Unless your eSATA is 6Gbps, my advice holds. The bleeding edge is the 6G SATA SSDs and they carry a 20% premium in price over the 3G SATA SSDs.
[Chris Harlan] “Well, lets see if that ends up on the next eight or twelve core. If–I guess–there is one. This would be a good year to add to the collection, but so far, no TBolt Mac Pro. And, for the first time in a long time, I’m wondering about HP or Dell.”
Unless Apple abandons the Xeon CPUs for the Mac Pro (and if they were going to, they would have by now), we won’t see a new Mac Pro before Q1 2012 when Intel finally ships the Sandy Bridge Xeons.
Best,
Andy -
We’re only talking about the render files that would arise from cutting promos, so minutes not hours, no? The 50TB of source material should go right on living on spinning disks. You could put your Projects and Events databases on an SSD and your media on your Glyphs. You might need to clean up your renders after a while, but that only takes a few clicks per project.
Remember, with FCPX the Events database is stored independently from Projects, and neither needs to live with the media (though if you choose to “optimize” and make ProRes out of everything, that will always live aside the Events database file). Even with all the various promos you’re making, there is no reason you couldn’t host the databases and renders on a single $400ish 240GB SSD and keep all the big data on the big RAIDs.
I should also point out that ideally you want the SSD installed internally, not in an external case. The low latency advantages of the SSD are going to take a hit hanging off a USB or FireWire bus. Unless you have one of the newest Thunderbolt Macs, you can also skip the more expensive 6G SSDs since you don’t have the 6G SATA bus to take advantage of them.
Incidentally, I highly recommend using an SSD for your boot drive. The difference in overall system responsiveness is very noticeable. It is so choice. If you have the means, I highly recommend picking one up.
Best,
Andy -
[Rob Mackintosh] “But that doesn’t explain the weird project bloating, and the resultant sluggishness, that occurs with markers, compound clips and when blading a clip.
As I understand it the undo queue is flushed when you quit. Perhaps the information is retained but not accessible and this contributes to the bloat? I know references to markers persist even when they’re deleted. I deleted over 10,000 of them and my project shrank from over 1GB to around 100MB.”
Yeah, it looks like you’ve identified a repeatable bad behavior. Smells like a bug, and you’ve got specific tests you can point to that demonstrate it. You should file a bug report.
Databases like SSDs, but bugs need to be squashed.
Best,
Andy -
[Rob Mackintosh] “There are no markers in the project. The audio exported from the project hasn’t changed. The project file is over a thousand times its original size.”
That sounds like a bug to me. Have you filed a feedback?
Best,
Andy -
[Chris Harlan] “Let’s see–my current project on FCP7=8TB @ $1,000 (2 4TB Glyphs/GRAIDS at current flood prices) vs. $15,000 (16 480GB OWC Mercury Electras). I’m thinking maybe us here in deployment land don’t like to hunt with that dawg.”
An 8TB project file! Wow, that’s gotta be a record… Oh, your media is 8TB. 🙂
Media should stay on spinning disk, of course. Fortunately, we can put projects on one drive and media on another.
The gotcha for FCPX is that it puts render files for the projects alongside the project files. Not ideal, I know. But if you are working on a one hour show, even rendering every frame is going to occupy less than 100GB (ProRes HQ 1080i29.97). One of those 480GB SSDs should handle that easily.
I’m not saying it isn’t a problem, these large and complex project files and the way FCPX interacts with them. I’m just saying there might be ways to tune your hardware and workflow to mitigate some of the issues.
Best,
Andy -
[Timothy Payton] “However, it seems like the issue could be resolved without having a SSD, but instead cache the entire DB to RAM, and instead of writing DB changes to disk, it would write to RAM, and then in a CUE to make changes to the disk. Just my 2 cents.”
That would be much faster. One technique that might work would be to queue transactions to RAM and commit them to the database the same time background rendering kicks off (idle mouse). Maybe that is impractical given other requirements we’re not privy to with respect to how everything under the hood of FCPX works, but if it could be done it would certainly be an effective workaround to low IOPS storage.
[Timothy Payton] “Actually I was more concerned with what was being added when importing a FCPXML into FCP X. Hence the 40 fold increase in the amount of data. Does that make sense?”
I’m certainly curious what is being accounted for in all those MBs.
[Timothy Payton] “I’m gonna run by the Apple Store today and I’ll try my FCPXML import on the fastest Mac I can find.”
Seek ye an iMac with the SSD option installed. Not sure if those are common in Apple Stores. The only Mac that is guaranteed to have an SSD is the MacBook Air.
Best,
Andy