John Heagy
Forum Replies Created
-
Are you going to speed up the on set song playback to 200% so they move to the beat or is there no correlation to the music at all?
John
-
[Walter Soyka] “But blades would be denser still”
True, but blades aren’t know for their GPU power which a render/encode farm could take advantage of.
John
-
[Dustin Parsons] “Anyone who though these couldn’t be rack mounted because of their shape wasn’t thinking very hard.”
Nobody said rack mounting theses would be impossible, only difficult. One could rack mount a bowl of Jello if need be.
Data centers will not invest in a custom built mounting/cooling system that only supports a specific model from one manufacturer. Unless of course you specialize in offering dedicated Mac servers like MacStadium.
The vast majority of data centers run multiple virtual machines on a single CPU via VMWare, and would have little need for dual GPUs that only generate heat.
Now a render/encode farm would benefit but they are a drop in the bucket…
John
-
I hope Apple realizes collaborative workflow is what’s keeping “The big guys” from using FCPX. They seem to think the current copying work around is sufficient.
Comparing a FCP7/Premiere workflow vs FCPX:
A single project file linked to shared storage vs a folder of project files linked to thousands of aliases contained inside multiple event folders and then linked to shared storage. It’s far more complexity with no real benefit in a shared environment. Apple tried to integrate a bit of the walled garden Avid approach but with none of it’s advantages.
John
-
I like the horizontal approach but with breakout panels at the back so you plug everything into the Mac then slide it in. All the connections would be present at the back. The last trick would be the on/off button which would need a front button connected to a lever contraption much like the Mini cases have.
Any device connected would also need to be rack mounted like the Promise SanLink in this case. These could be grouped together separately or under each row in an alternating fashion.
Looking forward to building my own Warp core.
John
-
Collaborative workflows on shared storage is what Apple needs to fix before we could use FCPX. It comes down to the nature of events for a local storage single user vs groups using shared storage. In a local system events can be shared with all projects, in shared storage they can’t. Oh… and copying is not sharing… it’s copying.
Admittedly not a concern for the vast majority of users and therefore not a concern for Apple it seems.
John
-
[Aaron Rathjen] “I was beginning to suspect this sort of contradiction going on between what FCPX is capable of for a single user, and how to manage those capabilities for multiple users in a MAM.”
Yeah I’m way beyond suspicion. I tried communicating this to Apple but they don’t get it. Seems they think coping is the same as sharing even though the instant one makes a change to the event the copy is out of sync.
For our shared workflow, events are simply a complication with no real benefit compared to having media directly associated to the project like FCP7. We would have to manage the project file and the event file where missing either renders the project useless. Not to mention the pointless redirection of every media file thru aliases.
Apple really made it hard for large shared workflows to embrace FCPX.
John
-
This brings up a catch 22 with FCPX… how to best use a MAM like CatDV when FCPX Events essentially is a built in MAM.
Ingest normally occurs in a MAM so ingesting into FCPX AND CatDV does bring up the question of synchronizing the two. The obvious solution is to only ingest in CatDV and then send to FCPX. But then what about all the workflow efficiencies during the edit that would be lost by not using FCPX Events fully.
A facilities’ MAM (CatDV) should be the final word on metadata… so what about metadata added in FCPX. Apple is quick to recommend an external MAM but fails to address the above issue when consistent metadata is required in a shared workflow.
Now FCPX and CatDV both support QT’s extended metadata model i.e. com.arri.ArriReel in the case of Arri ProRes files which could be used to “bake in” any metadata added in FCPX… if FCPX actually did that, which it doesn’t.
Sigh…
John
-
Hi Bob,
By expandability I mean expanding existing volumes without reformatting or loosing capacity when adding a larger chassis. I think the industry term for this is “scale out”. This is one of the issues we face with Xsan. Deploying new volumes makes sense to a point, but we’re at a point where we have enough volumes and need each volume to grow.
Scale out is where nobody can really touch Isilon. It was designed with that forefront along with chassis redundancy. GBLabs can be built in a way that lets you add disparate chassis sizes as well as chassis redundancy, but is requires a rather complex deployment. Islion even allows replacement of an older chassis without interruption.
Performance is really the question as far as realtime “do or die” ingest goes. EMC claims many media installations but many times it’s the consumer streaming side which is the case with MLB. David had no complains so that is really the first good report I heard first hand.
One can certainly build a faster small system with GBLabs as each Isilon node is only capable of 740MB/sec while GBLabs is 1400MB. Even worse – Isilon is a round robin write, much like Xsan storage pools, so no request could exceed 740MB while GBLabs will scale to a point.
Cost of course is the main issue with Isilon per Terabyte. The minimum system is a 3 node cluster in which case you loose 1/3 of capacity. Add to that the fact it has to grow in 3 node blocks, so with 3TB drives that’s an expensive big 200TB block. The nice thing about it is it gets more efficient and resilient the more nodes are added. The exact opposite of Xsan/StorNext.
David pointed out Coraid https://www.coraid.com/products/high_performance_nas which may have the best of GBLabs and Isilon with some compromises.
We’re really in the investigation stage but see the future being NAS.
John
-
We are still an offline/online house so once the Avid proxy is made we have plenty of time to produce ProRes files, so there’s no penalty in our case.
We shoot sLog so that all needs to get a one pass color correction. There are other factors that prevent us from using the camera media directly.
Our deadlines are frankly ridiculous. Shows are fibered out with less than 15min to spare routinely. We really need to do everything possible to smooth the online process.
We also rename and meta-tag the files so they can be linked via our custom software. Filenames like 2E001.mxf in the case of P2 are not good enough and will eventually repeat. This process also allows for partial file restore.
John