Andrew Richards
Forum Replies Created
-
[Bret Williams] “This system is incapAble of booting into 64bit on kernel on lion and certainly not on lion.”
Oh yeah, I forgot those can’t boot the 64-bit kernel with their 32-bit EFI…
Nevermind.
Best,
Andy -
[Mark Dobson] “I just think it’s important to start moving forward especially with the news that Mountain Lion will not run on some older 64-Bit Macs.”
The root of the 10.8 cutoff seems to be old GPU drivers that run on 32-bit kernel extensions, or “kexts”. Mountain Lion is the first OS X version to drop support for 32-bit kexts, so there is no way for the graphics cards in those older otherwise 64-bit Macs to work. But the Mac Pro is also the only Mac you can swap GPUs on, so while a stock 2006 Mac Pro with its factory GPU might not run MoLo, a 2006 Mac Pro with a Radeon 5770 might, since it would be loading the 64-bit kexts for that card upon booting.
A Retina MBP would still outrun it though.
Best,
Andy -
Glad to have you here, this isn’t a terribly active forum on the COW, but having a knowledgeable voice to fill us in on tape goings-on is always a good thing.
I have an LTO question: the spec calls for backward read-compatibility for two prior generations. Do any of the drive OEMs exceed that? Like, could we see an LTO-6 drive that can read LTO-3?
Best,
Andy -
[Ladislav Zamba] “Andy – I have Project and Event folder on internal drive. Only original media files was on USB2 disk.”
I understand, but I maintain that a single USB2 HDD is usually inadequate media storage for Pro Res. What brand/model USB2 drive are you using? They vary a lot.
[Ladislav Zamba] “And with SQL optimisation I was pointing to sequential vs. index searching in tables. Even if you have modern servers with lot of RAM, it’s not always possible to put 500GB table into RAM :-)”
Yes, developers should always optimize their code to be efficient, I don’t dispute that. All I’m arguing is that hardware is often a much more significant variable when it comes to NLE responsiveness. Software tuning will only get you so far.
500 GB tables? https://www1.hp.com/products/quickspecs/14212_div/14212_div.HTML“>No problem. Now if you’re getting into the 10s of TBs, then you’ll really have to spend some money!
[Ladislav Zamba] “What if Apple is planing to implement multiuser access to Events. Imagine 100 editors accessing same media at same time.”
Oh, that’s easy. Xsan (StorNext) can scale any which way you need. It ain’t cheap, but if you really have 100 editors, it can be built to handle it.
I stand by my original point- hardware performance is a lot more of a factor than software optimization when it comes to NLEs. Software optimization is very important, and should certainly be stressed, but at some point you bump up against physics and you just need a bigger boat.

Best,
Andy -
[Ladislav Zamba] “As old SQL database developer I’m aware of not optimal programming. For example not optimal SELECTs work fine with small databases on speed hardware, but with thousands of gigabytes of data such SELECTs are weak. And if thousands of users run such SELECTs at same time, servers are in trouble then.”
As a SQL developer you must also know that the most effective way to accelerate a database is to give it lower latency storage to operate on. Depending on the size of the database, that is often a matter of loading the entire thing into RAM. Moore’s Law and Brute force have been the saving grace of accelerating large databases for a long time, and the same is true for a 64-bit, hardware-optimized NLE.
[Ladislav Zamba] “My USB2 experience tells me that something can be made better.”
My USB2 experience tells me that it is some of the slowest, highest-latency storage you can get short of trying to edit over 100BASE-T.
[Ladislav Zamba] “Do you remember problem with doubling project file size when compound clip was made? Apple fixed it. So, I believe that FCPX developers can avoid some unnecessary disk activity and make editing on slow drives and machines faster.”
Maybe they could if you had a huge glut of RAM they could load more of the utilized source media into, since they have to store the timeline media somewhere if it isn’t going to be read from disk when called upon. However, for a large project, this too is untenable. Think about how much RAM you have, and then how much media you are using in your large project’s timeline. I can’t imagine what they could do to achieve what you are describing. Sometimes you just need better hardware.
That said, I do agree they need to optimize how FCPX assets are stored- specifically, allowing for separation of Render media from the Project database storage. The Events and Projects databases will be much happier on SSD, while the media can tolerate higher density, lower cost HDD arrays that are built for streaming media and not so good with the IOPS.
Best,
Andy -
Man, some harsh comments on Twitter around the #lafcpug #fcpx demo. Some of the attendees threatening bodily harm. You stay classy, LA.
Best,
Andy -
Andrew Richards
June 26, 2012 at 7:43 pm in reply to: Prognostications on FCPX compared to OSX and iOS from Alex4D[Walter Soyka] “The local machine was a Premiere thin client, and the remote machine was the server actually responsible for all the media storage and realtime rendering and streaming.”
Avid has something like this in the works too, don’t they?
Best,
Andy -
Andrew Richards
June 26, 2012 at 4:17 pm in reply to: Prognostications on FCPX compared to OSX and iOS from Alex4D[Jeremy Garchow] “Yeah. Total coinkydink.”
It really does probably have a lot more to do with Oracle’s acquisition of MySQL in 2009 than anything related to MAM product plans (if any even exist).
Best,
Andy -
Andrew Richards
June 26, 2012 at 3:43 pm in reply to: Prognostications on FCPX compared to OSX and iOS from Alex4D[Franz Bieberkopf] “There was a discussion on issues with network media – I think it may have even been Jeremy? Search is failing me. Solution was to keep things on the boot drive, including renders.”
It was Oliver and storing the Events and Projects on a FibreJet SAN. The solution was local storage as opposed to that particular SAN, and local storage does not have to be the boot volume.
Best,
Andy -
Andrew Richards
June 26, 2012 at 3:41 pm in reply to: Prognostications on FCPX compared to OSX and iOS from Alex4D[Franz Bieberkopf] “From what I’ve seen of the software and read here in the forums, it just strikes me that “workflow” was entirely an afterthought to FCPX design: renders kept with the project file which is designed to be kept on the boot drive. Really? At what point in the design process was that idea analyzed and arrived at as the ideal solution? Using the finder to organize projects?”
Was anyone complaining about this with FCP Legend? It was the same story there- everything defaulted to the user’s Documents folder, including all scratch disks. They have to default it that way, the boot volume is the only one they can always assume exists. It has always been up to the user to provide and assign alternate storage. I do wish FCPX let you assign Render storage separately from Project storage though.
[Franz Bieberkopf] “A better database and workflow model is certainly needed (as per your post) but right now that prize is up for grabs and it doesn’t seem to me that Apple has any particular advantage built into its software, nor any particular drive in that direction.”
Unless they release a much deeper API than XML, Apple is the only one who can do it the way I described it. I too question their interest in doing such a thing, except perhaps if they want to push the limits of CoreData and use FCPX as a bellwether. I suspect they are already using it to push AVFoundation and OpenCL on OS X, so it isn’t impossible that they’d take a stab at a new sort of Final Cut Server made up of shared Events and Projects databases.
Best,
Andy