FORUMS: list search recent posts

Large projects

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Oliver Peters
Large projects
on Nov 23, 2011 at 5:19:43 pm

http://fcp.co/final-cut-pro/news/654-so-how-fast-does-fcpx-work-with-3344-c...

Thoughts? Seems like it would be less painful in the list view. But maybe not.

- Oliver


Return to posts index

Steve Connor
Re: Large projects
on Nov 23, 2011 at 5:35:04 pm

FCP classic used to be painful with large projects as well, it was only in the later versions that it improved. Hopefully it wont take as long with FCPX.

"My Name is Steve and I'm an FCPX user"


Return to posts index

Andy Neil
Re: Large projects
on Nov 23, 2011 at 6:14:25 pm

This is one of those things where I think the designers considered all they could do with 64 bit processing (clip skimming, filmstrips in the timeline, big thumbnails and filmstrips in the browser, dynamic database searches, background transcoding) and didn't consider the hardware limitations of current computers with large scale projects.

I too think it would be faster with list mode, and I also wonder just how fast ANY NLE would be searching for 3 clips amongst 16,000, but there does seem to be a fundamental issue with the priority given to the display of clips over the management of the database.

I would like to see the ability to turn off some of these "enhancements" when working on larger projects to keep it snappy.

I also think his suggestion is completely reasonable to have search looking through all the events if nothing is selected. Then you don't have the problems of caching and building thumbnails for all those events.

Andy

http://www.timesavertutorials.com


Return to posts index


Franz Bieberkopf
Re: Large projects
on Nov 23, 2011 at 6:22:36 pm

Sometimes I see stuff and just shake my head ...

I guess speed wasn't a design priority.

"I don't know; I'm not a programmer." (from the video)


Franz.


Return to posts index

Matthew Celia
Re: Large projects
on Nov 23, 2011 at 7:24:03 pm

I posted this over on that post, but I am cutting a doc and have to say I'm most disappointed with the responsiveness of the timeline. While I save a lot of time being able to skim and look at the thumbnails, sometimes moving clips around in the timeline and zooming in and out can be a huge pain. I often work in list view, and switch the thumbnails off in the timeline (working either in capsule, or audio only mode). It helps a little bit.

Just FYI, I'm on a 3.4 Ghz i7 with 16GB ram, 2GB ATI card. I bet the bottleneck in my system is the drive, however. (FW800 G-Raid). To help, I am cutting with proxy files, so the video is always flawless, but when it comes to the slow responsiveness of the NLE, I have to wonder if having a Pegasus Raid would speed things up.


----------------
FCP Guru
http://www.fcpguru.com


Return to posts index

Oliver Peters
Re: Large projects
on Nov 23, 2011 at 7:28:46 pm

Has anyone done any project responsiveness comparisons of working in Events/Projects/timelines where the files are only references (links to other locations) vs. optimized media vs. proxy media?

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index


T. Payton
Re: Large projects
on Nov 24, 2011 at 1:39:18 am

Matthew - Here is what I found helpful when working on large projects:

- Edit in a Project, not a compound clip in the Event. (I was doing this for smaller projects, on big projects it is a killer.)

- File size of the project file will indicate exactly how slow or fast the timeline will respond. I've got a 1 hr project with a 126MB project file and it crawls. I've got a 4 hour project that is just 4MB and it screams. Things that increase the size of a project file is split up compound clips that have lots of anything: edits, markers, ranges, etc. See here:



and here:





- Every keystroke saves to the super inefficient project file, so on a large project lowering the volume of a clip by multiple keystrokes, or trimming, or color correction will grid the poor thing to a crawl.

- Audio filters, are actually processed as you edit - so best to leave out any filters, denoise, etc. anything but levels until a final mix.

- Close the timeline index - at least on my machine it slows things down.

- Group your long project into compound clips for each scene. FCP X seems to like this a little bit. Doesn't do anything for the file size but you'll find editing inside the compound clip timeline will go much faster (at least it feels faster) than having everything "broken apart" in the main timeline. My one hour project I divided into about 15 scenes. So once I opened a scene, everything moved much faster.

- Watch your ram. I have a little free app from the Mac App store called "Free Memory" it will list your free ram on the menu bar. Very helpful. To free up ram, just quit FCP X.

- Turn off background rendering. In fact don't render at all. Unless you are using some complex effects it is just as fast to export without rendering that waste all the CPU cycles rendering while you edit.

- Only let FCP X see event you are using and the one project you are working on loaded. Even having an external drive with a even or project on it that FCP X can see will slow it down to a crawl.

I've been working in FCP X on a variety of projects, and I am just amazed and the incredibly inefficient way projects and events are stored (see my videos above). It feels like I am working in a program that can only do one thing at a time. This is so unbelievably bad, that it has to be at the top of the list for the FCP X team. In fact pretty much 90% of the problems I have with FCP X is performance. They have to fix it!

------
T. Payton
OneCreative, Albuquerque


Return to posts index

Oliver Peters
Re: Large projects
on Nov 24, 2011 at 1:48:09 am

[Timothy Payton] "Matthew - Here is what I found helpful when working on large projects:"

Wow! I thought you liked the program ;-)

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Franz Bieberkopf
Re: Large projects
on Nov 24, 2011 at 2:12:27 am

Timothy,


Thank-you for posting this. In almost six months since the release of FCPX I haven't seen any information like this, and as I tend to work on larger, longer projects this sort of information is fundamental and crucial to my evaluation.

I am frankly astounded that such performance issues weren't primary for the FCPX design team.

Manually managing memory ...

Breaking sequences into "more manageable segments" ...

Turning off the much marketed "background rendering" ...

Leaving audio work until the mix ...

I really have no words beyond the ellipses. Where is Aindreas when you need him?


Franz.


Return to posts index


Jeremy Garchow
Re: Large projects
on Nov 24, 2011 at 2:49:02 am

This sounds awful, Timothy.

Would you mind posting your system specs again?


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 24, 2011 at 3:10:20 am

Also, I noticed you're working with a 22k mp3.

Does the type of media matter?


Return to posts index

T. Payton
Re: Large projects
on Nov 24, 2011 at 5:23:45 am

Well I didn't mean to say too many negative things about FCP X. ;) I really do like the program, in fact I think it is brilliant concept, but a poor execution at the moment.

So pardon me for throwing Apple under the bus, but in my view Apple has had a bad track record of creating apps from scratch on the Mac. The original iPhoto, Garageband, Pages and Numbers were painfully slow. iMovie (the new one that is like FCP X) was and is very slow. I encouraged some friends to get an iMac (an i5) last spring to do some student video work (actually very complex) and they came back and said "Why is it that every time we do something in iMovie it has that spinning ball?".

Final Cut Pro was not like that, and it wasn't begun at Apple. It was speedy from day 1. But the home grown apps like Live Type, Motion, and even the beloved SoundTrack Pro were slow and awkward -- especially if you compared them to other apps like After Effects and Pro Tools on my same hardware.

Now the good news is that many of these Apps Apple has fixed. Pages for example. At my advertising shop my fellow designers LOVE Pages. It can do about 90% of what we used to do in QuarkXpress back in the 90's. SoundTrack Pro got much better and Motion has matured too.

I know Apple can make FCP X work if they want to. I know this because I use GarageBand on my iPhone. yeah my iPhone. It is amazing! I'm recording song ideas in multitrack on my iPhone that I did 8 years ago in ProTools. The program is very responsive, and it just works. Every little detail has been well thought out, and when I use it on my first gen iPad it is even better.

So what is up with Apple? This is a company who are able to make Garageband work on a tiny device with a tiny amount of ram. If they put their mind to it they can do almost anything. Now I don't know what happened with FCP X development, but something went horribly wrong. As we all know the launch was very un-Apple like, and a branding disaster; Where were the endorsements from people like AJA, Blackmagic, Broadcast stations, famous film editors? So the features changed, but as those of us who have stuck with the App for a while know, the lack of features are not really a problem. In fact I continue to be amazed at the brilliance and simplicity that went into the design of FCP X.

The design on paper is brilliant, but the execution fell short. In my book the concept gets and A, execution and attention to detail gets a D. (No keyboard commands in the precision editor? Can play back nearly anything in real time at whatever resolution, but too many edits on the timeline and it stalls for several seconds when trimming a clip?)

It's kinda funny because in my business, advertising, we see the opposite true most of the time. Horrible concepts but unbelievable slick executions. It's lipstick on a pig. But in the case of FCP X, its ragged clothes on a sawn.

So I have great respect for Apple, and the programmers. But they have shown that they are human, like the rest of us, and have blown it. I'm willing to give them the benefit of the doubt, as I have been given the benefit of the doubt many a time. Plus FCP 7 still works well if I need it.

My specs:
MacPro, 2006, 2.66 GHZ (4 core)
14GB RAM
Radeon 5770, 1GB
eSata RAID (130MB/sec)
10.6.8

P.S. While my machine is no spring chicken, the problems I am giving as examples effect any machine.

------
T. Payton
OneCreative, Albuquerque


Return to posts index


T. Payton
Re: Large projects
on Nov 24, 2011 at 5:07:49 pm

I apologize for my previous post was so long--the effects of posting tool late at night.

Just did a quick test that showcases my concern about the project file inefficiency:

Took my 1 hour 15 minute timeline, about 2000 edits.
FCP X Project File: 126mb
Exported FCPXML. 1.2 MB

Imported 1.2 MB FCPXML on my MacBook Pro:
Took about 5 minutes
New Project File: 43MB

Therefore FCP X Created 41.5 MB of data when importing the FCPXML. There was no additional "real" project information because no media was available, as it was on a completely different machine. i.e. it couldn't create new render files, waveform cache or thumbnails. This is needless bloat. BTW. Maneuvering in the imported timeline with no media to access is about the same speed it is on my MacPro that has all the media available - very slow.

For comparison, via Automatic Duck I moved the timeline to FCP 7.

FCPX Project File: 43MB
AAF Export from Automatic Duck: 13 MB (link to existing media)
FCP 7 project file: 5.3 MB.

Concerning the Database Records, although I'm sure speed would help, I would conclude that it isn't SSD's or a Thunderbolt RAID that is needed, but instead a serious look at the database structure. Concerning the database, I have several large mySQL databases that run web sites on my web server. The hardware is 2.1 GHZ, Dual Core, 4 MB of Ram, and a regular old 200 GB sata internal drive. Typically the database files are small, about 2mb. But I have a very large site with a 67MB database, 168,683 records. Does the size of the database effect the speed? Not that I can tell at all. Typically my queries to return a hundred or so records are less than .5 seconds. Adding a record to the database just took 0.2085 seconds. Just as they are on a site with a small 2MB database.

Now I don't know alot about SQLLite (which as far as I can tell is the structure of the FCP X project and event files) but I did a quick Google and found this: (it may or may not be relevant) Basically it says "As you can see, most operations are slower on SQLite3 and “write” operations (create/update/delete) are really bad."

http://zenadmin.org/en/blog/post720.html

So there are two issues here. 1) project databases has unbelievable bloat. 40 units of bloat for every 1 unit of real data. 2) database access is incredibly slow, which seems to get worse with size.

I would conclude from this that the database format that we currently see in FCP X is horribly flawed. If I were a project manager, I would get as many programmers as possible and set this as the top priority. Either scrap it completely or do a rewrite. Although a complete rewrite sounds like a big deal, and I can't dream of working on a large project like FCP X, I have done smaller rewrites of database structures and it is often needed during the coarse of a project. It is going to be what determines if FCP X flies or not. No amount of hardware you throw at it can help.

I would encourage all of us to send Final Cut feedback to Apple regarding this issue. They have to know it is a problem, but perhaps our feedback will let them know how problematic it is.

So I have not lost heart with FCP X, not at all! Apple can get this fixed, and I'm confident they will.

Happy Thanksgiving!

------
T. Payton
OneCreative, Albuquerque


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 24, 2011 at 6:00:44 pm

Thanks Timothy for this in-depth and impeccably argued overview of what is clearly one of the biggest hurdles that FCPX has to overcome - and quickly!

Have a great holiday!

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 24, 2011 at 10:28:34 pm

good christ.

also its strange to see calm collected investigation as opposed to the native froth loopiness of crazed natives like, well, me.

if...

if apple have in fact walked FCP this far down architectural FUBAR - if it is at subsidence level - is there a basis for thinking they have the wherewithal to walk it back out?

how many software engineers are left working on this thing anyway?

ah god.

annnyway besides - and indeed - happy thanksgiving peeps one and all.


(last ever time for this)

ancient quote from the assembled mass of humanity on this day of thanksgiving, from their gods, their elders and their forebearers:

"Randy Ubillos, you scion of editing intelligentsia, you visionary of time - we thank you Randy for this steaming, brown, curled, strangely smelling, but surely wonderful, wonderful editing bread. thanks for what you took the time to do once you got bored by the strictures of editing as we understood it.
And so it is that we truly thank you Randy, for what you did to Final Cut Pro."



http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index


T. Payton
Re: Large projects
on Nov 24, 2011 at 10:51:45 pm

[Aindreas Gallagher] "good christ. "

Actually yes He is very good. ;)

I do think that Apple is able to fix this. (hence my example Garage Band for iOS. It is incredibly well executed.) Although the database problem is pervasive and seems to effect everything in FCP X, it is still the execution that is the problem and not the concept. While I don't want to make this sound trivial, from my perspective it is fixable.

Kinda like getting into editing and realize that everything that was shot that day won't work and you have to shoot again. An annoyance? yes. Will it cost you money? yes. Fixable? Absolutely.

The most difficult call for Apple is simply devoting the resources, and making the call to go over how "CurrentVersion" is stored and accessed with a fine tooth comb. Even if they do a complete rewrite on that one "module" or Framework, it is actually one of many elements that make up FCP X. They will make a translator in a future version of FCP X, and no-one will notice. Every indication I have heard Apple say publicly about Final Cut, they want to fix FCP X.

------
T. Payton
OneCreative, Albuquerque


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 24, 2011 at 11:59:40 pm

sorry sir, I do a tad tend to use the lord's name in an Irish fashion...

True indeed with garageband, it is mindboggling on the 1st gen ipad. I just wonder a little if the banal intricacies of a good editing system, fit to perform in a niche market, is realistically within the scope of their efforts.

as you say, we'll know in fairly short order. I'm minded by looking at their native efforts with STP and motion though. they were both, ultimately, kludgy software with almost no market traction outside of the wake of FCP. I don't actually think either of them are objectively particularly good software in hindsight? neither did they have a real life outside of the halo of FCP.

all the serious stuff was brought in - FCP itself, shake, colour, logic - (which I don't know)
I think... it is an unspoken truth that apple's own efforts show an attempt at pro software from a company not outfitted to produce pro software?
Motion was heavy and unwieldy (although haven't used the newest) - and it was buggy. I had to personally try to architect it to be database driven to provide automated multiple GMT lower third endboards for a station launch and I found it genuinely horrible in action. just heavy and chrome filled. make comparisons at will...

So was STP. And STP I knew pretty well.

Apple, I find, make a form of software that looks sort of right when you launch it, sounds interesting, and appears to have interesting workflows, but it ultimately tends to be a slightly gloopy curio. It is as if the software engineers never knew professional hunger - there is a lack of operating empathy in how they go about things - they are just wandering around making idealised scenarios that please in the boardroom demo? that there is, and has never really been any ear at all to the ground?

that aloofness represents brilliance in the consumer market and allows them to leapfrog entire markets intuitively, but as an impulse, it is utter poison to the provision of workable, scalable professional software. I don't think apple are any longer in a mind position to produce workable professional software. They are completely deaf to any critical signals - and, if larry jordan is to be believed, they wilfully ignore deafening signals coming in on private channels during their rather paper thin betas.

Ultimately - I think that Apple are institutionally (and in a way, for the best of reasons more broadly,) incapable of fostering any of the co-operative customer base relationships critical to the production of this type of software.
You cannot simply toss the puck in the air and skate to where you think it lands in five years: because you are not talking about the whims of consumer habits, you are talking about entire invested industries and countless livelihoods.
That's not really a puck throwing scenario.

I'd argue that any professional software produced by Apple corporation is currently, (and will for the foreseeable future be), somewhat beautifully made but largely unusable white elephants on sale.

(long reply!)


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 12:47:20 am

The surprising aspect to this is that Apple isn't totally clueless about databases. After all, once indexing is done, Spotlight returns search results at blinding speeds. Filemaker Pro is highly regraded and that company is a subsidiary of Apple. Although Bento isn't particularly fast.

As a point of comparison, take a look at Vegas versus FCP X or Numbers versus Excel. In the latter example, Numbers is friendly and attractive, but completely chokes on 3,000-entry spreadsheets that don't even give Excel a pause. All on the same machine. I can run Vegas under Parallels and Windows on my Mac Pro and have a very satisfying experience.

It's quite possible that too much of the database handling came over from FC Server. It's not a particularly good asset management tool and when it works well, it's running under Mac OS X Server usually on an Xserve. If that's the case, then there are some built-in design problems.

Remember, that Ubilios gave us FCP 1 as well as X, so a better product was a possible result. I believe Aperture came out of the same team and the market goes back-and-forth between it and Lightroom as to the preferred photo app. I suspect that if ProApps were spun off as a subsidiary forced to justify its existence based on products, you might actually have better results.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index


Aindreas Gallagher
Re: Large projects
on Nov 25, 2011 at 1:20:45 am

Honestly Oliver, I'm not sure this stuff was ever their bag? They paid a fierce amount of attention half a decade ago - but do you think there is a worldclass pro-video coding group in Apple? Honestly?

there were rampant rumours here a few months ago that the FCPX software coding got hived off to the itunes team for gods sake.

they fired most of the pro-apps team in early twenty ten?

I.. just don't think there is the makings or numbers for a pro editing app in Apple full stop?
like its going to be a slow grind to halt over 24-48 months aperture style.
..Do you think there are two people in apple that care about aperture?

Put it this way - this X application say is motion right? but with no bought in FCP ecosystem to back it up. stands or falls on its own.
As in FCPX is, intellectually, as a choice - motion, on its own, with no industry standard like FCP7 to underpin it. that is how weird FCPX is.
As buggy as motion, as weird as motion relative to the target market, possibly as under resourced as motion.

Apple, in ten years, have no signature professional software to their name, in ten years they have created - none - they bought in some, and then they just killed all of them.

Why is FCPX different? Its just as buggy, just as glommed in chrome, just as obtuse relative to industry practise - how did motion throw behaviours get on?
they killed after effects right?

Primary storyline is a world beater. Oh no wait - its not. Its just some useless stuff Apple came up with all on their own that the entire industry is going to completely ignore - because it is a useless conceit in a buggy chrome heavy application that apple is, like clockwork, going to forget about in three years time.

Again - Randy. Ubillos.
Thanks for this. no really - thank you for making January Learn Avid month. This is all - just great.


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 1:48:42 am

[Aindreas Gallagher] "FCPX software coding got hived off to the itunes team"

I don't think that's a fair statement. Apple uses certain software engineers who touch various unrelated products. For example, there are UI designers who have touched all of these. I think you have to differentiate people doing the nuts and bolts coding from those that conceptualize features in the product and how it should work.

[Aindreas Gallagher] "they fired most of the pro-apps team in early twenty ten"

I doubt that's true. Supposedly 40 QA or support staff were let go. That's hardly "most" of ProApps.

[Aindreas Gallagher] "Do you think there are two people in apple that care about aperture"

Actually yes, because it helps to drive iMac and 27" display sales and is part of the Photostream ecosystem now.

[Aindreas Gallagher] "Again - Randy. Ubillos"

I have no issue with this. Right or wrong, he's developed 3 (or 4 depending on your POV) NLEs from scractch - Premiere (original), FCP, iMovie and FCP X.

[Aindreas Gallagher] " January Learn Avid month"

Good move. MC6/Sym6 is very solid in spite of a few .0 bugs. It's the industrial-grade solution.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 25, 2011 at 2:30:00 am

sure what is "most of pro apps team" tho?

they used to run a ton of apps - now its a lone editing app built out of imovie and legacy motion - sure isn't the point we have no idea what is left in there?

and.. I read some reasonably persuasive stuff that the QA line was a tad PR driven, given where, geographically, people got fired, and where the relative departments were.


Also I'm leery of the notion of Ubillos as the godfather of editing. the version of premiere he developed was crazy. I had to use it at college. if you look it up, there are some insane comments he made defending its short comings at the time- seriously google it, its also waay down the comment thread, but he really said whacky things way back when about availability of plugins and stuff (I'm iffy - look it up!).

Surely Randy Ubillos is ultimately a guy in a job, a brain heavy industry high profile job sure, but its job, he's not a pope, and he just drove an industry standard software platform into a wall at 85kph.

Discovery has dropped FCP, CNN has dropped FCP, the BBC has dropped FCP, a whackton of third level has dropped FCP. Isn't there a limit to this?
positing that some mythical new entrants will upend the market with this weird buggy software does. not. hold. water.

Ubillos wrecked the house. He wrecked the FCP house. He actually trashed it.


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Dennis Radeke
Re: Large projects
on Nov 25, 2011 at 12:22:26 pm

[Aindreas Gallagher] "Also I'm leery of the notion of Ubillos as the godfather of editing. the version of premiere he developed was crazy."

It's good to mention that Randy has had nothing to do with Premiere Pro in a very long time. Premiere Pro was a complete re-write. CS3 went back to the Mac and CS5 was 64-bit. The A/B Roll methodology of the old Premiere is long gone with V1 of Premiere Pro.


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 4:06:10 pm

[Oliver Peters] "It's quite possible that too much of the database handling came over from FC Server. It's not a particularly good asset management tool and when it works well, it's running under Mac OS X Server usually on an Xserve. If that's the case, then there are some built-in design problems."

FCSvr ran on top of a PostgreSQL database that was being queried directly by the Java front end. FCPX calls CoreData to transact with SQLite databases (that's all CoreData uses). Perhaps there are some schematic similarities between the two, but probably only at a high level (if at all). There are virtually zero architectural similarities given the technologies each uses.

I also disagree with your opinion of FCSvr as an asset management tool, but that is another discussion for another forum.

Best,
Andy


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 4:20:27 pm

[Andrew Richards] "I also disagree with your opinion of FCSvr as an asset management tool, but that is another discussion for another forum."

Thanks for the clarification. My perspective is strictly as a user. The comparison of DAMs was as compared with Avid Interplay or CatDV.

I like a lot of the functions the FcSrver does. Just not fond of how it works as purely a DAM tool.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 4:30:18 pm

[Oliver Peters] "The comparison of DAMs was as compared with Avid Interplay or CatDV."

CatDV does have much more in terms of asset manipulation for the end user. FCSvr was great for the admin (me). I've never used Interplay.

Best,
Andy


Return to posts index

Frank Gothmann
Re: Large projects
on Nov 25, 2011 at 12:58:30 am

Actually, your mentioning of Soundtrack Pro here is scary and brings back very unpleasant memories of working with it.
SP shares some code borrowed from Logic but it has been written by a completely different team at Apple. Logic still has veteran guys from the original Emagic on board.
The differences in performance and stability between the two apps is like night and day. So much so that it is hard to believe they were sold by the same company.


Return to posts index

Chris Harlan
Re: Large projects
on Nov 26, 2011 at 9:28:17 pm

[Aindreas Gallagher] "Randy Ubillos, you scion of editing intelligentsia, you visionary of time - "

It didn't really occur to me until reading this--but could it be that Randy U. is a lost son of Gallifrey, and like the Master before him, has reclaimed his place as a Time Lord and is, even now, preparing to face down the Doctor (and Amy and Rory) throughout the whole next season (or, just the Christmas Special?) Could FCP X be one of the first of many advanced, multi-dimensional, planet-chrushing weapons in his arsenal? Is the iPad3 really a TARDIS?


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 26, 2011 at 9:54:46 pm

chris good sir, you speak to my deepest second heart.

I met tom baker back stage on 'the mask of moriarty' at the gate theatre in dublin, aged twelve, courtesy of the mother who is forty years treading the boards in our town.

He leaned down and boomed "helllooo" with a big, impossibly toothy grin. He was just great. Insane childhood highlight.

I do rag on Mr. Ubillos to a ridiculous degree given I'm a pleb, but.. I am savagely inclined to tweak his nose. said the gnat on the windshield.

that aside: the doctor's wife?

BEST. BLOODY. EPISODE. EVER.

Neil Gaiman ftw.


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Chris Harlan
Re: Large projects
on Nov 27, 2011 at 4:35:16 am

Tom Baker! You lucky pup. As far as my childhood self was concerned, he was THEEEE Doctor. His face still comes to mind at the Doctor's mention, just before the others. All three of the last Doctors give him a run, though, with David Tennant a bit in front.

[Aindreas Gallagher] "that aside: the doctor's wife?

BEST. BLOODY. EPISODE. EVER.
"


Agreed! Or nearly so. That or the "Are you my Mommy?" two-parter. Though "Let's Kill Hitler" has a lot of bang for the buck. My daughter and I are greedily awaiting the Christmas Special.


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 3:53:04 pm

[Timothy Payton] "I have several large mySQL databases that run web sites on my web server. The hardware is 2.1 GHZ, Dual Core, 4 MB of Ram, and a regular old 200 GB sata internal drive. Typically the database files are small, about 2mb. But I have a very large site with a 67MB database, 168,683 records. Does the size of the database effect the speed? Not that I can tell at all. Typically my queries to return a hundred or so records are less than .5 seconds. Adding a record to the database just took 0.2085 seconds. Just as they are on a site with a small 2MB database."

I don't think the sheer size of the database is the issue, but rather the volume of queries (and possibly the nature of the queries). How would your mySQL database fare if it were getting hit with tens or hundreds of concurrent queries? Even if you could assume your performance wouldn't suffer under many concurrent queries (it would), your .5 and .2 second benchmarks quickly become whole seconds, and that's going to feel slow. If every little thing FCPX is doing is being logged in a database, we can expect a lot of transactions to be taking place virtually constantly. Spinning disk is going to struggle with that no matter how it is connected to the host.

[Timothy Payton] "Now I don't know alot about SQLLite (which as far as I can tell is the structure of the FCP X project and event files) but I did a quick Google and found this: (it may or may not be relevant) Basically it says "As you can see, most operations are slower on SQLite3 and “write” operations (create/update/delete) are really bad.""

FCPX is calling CoreData, and that is what uses SQLite3. Maybe CoreData isn't up to the task of the kind of strain an NLE like FCPX places on it, or maybe the schema implemented in FCPX is to blame.

[Timothy Payton] "So there are two issues here. 1) project databases has unbelievable bloat. 40 units of bloat for every 1 unit of real data. 2) database access is incredibly slow, which seems to get worse with size."

The level of detail in FCPXML is clearly much lower than in an actual project. FCPXML doesn't even retain audio levels. The telling thing to me is your original project was three times bigger than the one that resulted from importing the XML. We don't know what is getting stripped out along the way from FCPX Project to FCPXML to AAF to FCP7 project, so judging them strictly by file size isn't really telling a complete story. Maybe it is bloat, maybe CoreData is inefficient given that it is an abstraction layer between the app and the actual SQLite database, maybe it is bad design, or maybe it doesn't matter much because the real bottleneck is the IOPS performance of the storage that hosts the database.

[Timothy Payton] "I would conclude from this that the database format that we currently see in FCP X is horribly flawed. If I were a project manager, I would get as many programmers as possible and set this as the top priority. Either scrap it completely or do a rewrite. Although a complete rewrite sounds like a big deal, and I can't dream of working on a large project like FCP X, I have done smaller rewrites of database structures and it is often needed during the coarse of a project. It is going to be what determines if FCP X flies or not. No amount of hardware you throw at it can help."

Leaving aside the myth of the man-month, I don't agree that we have any kind of conclusive evidence this is strictly bad software and that hardware has nothing to do with it. There probably is lots of room for performance tuning with respect to how FCPX is calling CoreData, and there is probably also room for improvement of CoreData itself. No software is perfect and can always be improved upon. However, dismissing the role of hardware out of hand when database performance is in question is simply incorrect. IOPS matter a ton for busy databases. Contemporary consumer SSDs at their worst will deliver about 100 times the IOPS performance of a typical SATA HDD. That kind of gap absolutely matters in this analysis.

Storage requirements are a well-known factor when it comes to streaming video for an NLE. If you don't have the bandwidth, you are going to drop frames. Period. The same thing holds for databases. If you want to go fast, you need high IOPS storage. The net benefit of using storage that is hundreds or even thousands of times quicker than spinning disks is going to deliver a much higher return than software tuning.

It's fair to criticize Apple's decision to go with an auto-saving-persistent-database model instead of a volatile-memory-to-flat-file model like they had in FCP7, especially in light of the problems it introduces. Both approaches have their plusses and minuses. I just don't agree that there is nothing we can do about it, such as it is, out here in deployment-land.

Best,
Andy


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 25, 2011 at 5:22:43 pm

OK, so let's forget large projects for a second. Here's a very simple experiment I have just tried.

New Event, new project - import one 2 minute clip (1080P ProResLT 23.98fps), drag it into a matching timeline. Project file size is 401K. (Note that I did this a few times and the intial file size with exactly the same paramters is erratically different, but that's another matter.)

Next I bladed the clip 20 times (nothing else, no markers, no effects, nothing at all). Project file size is now 3MB - every edit significantly increased the filesize by getting on for 100K. (And I get a comparable result when using the range tool to select and cut 20 portions of the same clip.)

This is not good.

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 25, 2011 at 7:18:29 pm

Another experiment:

Loaded 57 minute aiff into new project.
Placed on primary storyline, put into compound clip, opened compound clip.
Project about 150KB in size.

Added 10 markers at 5 minute intervals.- showing 10 markers.

Cut aiff file into 152 clips. Exported XML showing 1520 markers.

Deleted markers. Exported XML showing 1520 markers. Project size about 6MB.

On primary storyline cut compound clip into 10. Exported XML showing 15100 markers.
Project file around 60MB. XML file 1.9MB

Cut compound into 30 separate clips. Exported XML showing 45300 markers. Project file now 175 MB. Takes a minute to load.

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.


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 25, 2011 at 7:25:11 pm

I think your point about markers - which you have been trying to get people to recognize for a while - is a very good one. But your experiment is pointing to an even more basic problem which is the monstrous rate of growth of a project when all you are doing is splitting a clip into pieces on the timeline.

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 25, 2011 at 7:42:23 pm

Agreed.

And it puts a dampener on one of the potential strengths of FCPX - versioning in the timeline.


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 25, 2011 at 7:47:38 pm

It's a fundamentally significant issue - it's extraordinary that it's not being picked up on more. Thanks for trying to keep the ball in the air on this one as it's something people should really be aware of and be lobbying Apple about as much as possible.

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Steve Connor
Re: Large projects
on Nov 25, 2011 at 8:15:06 pm

Haven't spotted this at all in all my FCPX projects, but I haven't been using compound clips or markers very much. It's a very worrying development.

"My Name is Steve and I'm an FCPX user"


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 25, 2011 at 8:15:41 pm

Thanks for all the free effects. Brilliant, as they say on The Fast Show.

As Andrew Richards explains there may be issues relating to the autosave and concurrent queries to the database. Some optimizing and faster hardware might solve that.

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.

Essentially all media in FCPX can be treated as a sequence.
What are the ramifications of this?


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 10:13:51 pm

[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


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 10:03:28 pm

[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


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 26, 2011 at 1:39:19 am

Yes, a couple of weeks ago.


Return to posts index

T. Payton
Re: Large projects
on Nov 25, 2011 at 5:55:09 pm

Andrew-

Great points. Excellent feedback.

You are much more familiar with database issue than I am. It is especially noteworthy that you pointed out that there are many simulations queries required. 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.

[Andrew Richards] "We don't know what is getting stripped out along the way from FCPX Project to FCPXML to AAF to FCP7 project, so judging them strictly by file size isn't really telling a complete story."

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 gonna run by the Apple Store today and I'll try my FCPXML import on the fastest Mac I can find.

------
T. Payton
OneCreative, Albuquerque


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 6:17:53 pm

[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


Return to posts index

Chris Harlan
Re: Large projects
on Nov 25, 2011 at 8:31:42 pm

[Andrew Richards] "Contemporary consumer SSDs at their worst will deliver about 100 times the IOPS performance of a typical SATA HDD. That kind of gap absolutely matters in this analysis."

and

[Andrew Richards] "I just don't agree that there is nothing we can do about it, such as it is, out here in deployment-land."

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.


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 9:58:14 pm

[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


Return to posts index

Chris Harlan
Re: Large projects
on Nov 26, 2011 at 6:52:03 am

[Andrew Richards] "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.
"


Andrew, I'm delighted to hear that the source material can remain on regular RAIDS. BUT, we are talking big projects, right? I'm doing advertising packages for multiple seasons of broadcast TV over the next four months, most of it in 1080i@29. I'm guessing I will have a little over 50 hours of programing as source material. I will need access to all material throughout the project, and each promo has multiple versions. So, to follow your plan, I'm guessing that I need more than just one of those 480GB SSDs. So, maybe not $15000, but maybe 4000 or 6000 plus the cost of a Glyph? It still seems to me an issue.


Return to posts index

Andrew Richards
Re: Large projects
on Nov 26, 2011 at 2:33:59 pm

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


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 26, 2011 at 3:04:32 pm

[Andrew Richards] "It is so choice. If you have the means, I highly recommend picking one up."

"Ferris, he never drives it. He just rubs it with a diaper."


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 26, 2011 at 3:25:28 pm

I would imagine that multicam will get handled with some sort of compound clip (just a guess) that this will need to handled/addressed.

I am away from FCPX at the moment, but...

What happens of compound clips are made in the event? Does the event bloat?

What happens if you quit FCPX and reopen, does the bloat remain?

It's no so much the size of the projects that worry me, it's performance.


Return to posts index

Herb Sevush
Re: Large projects
on Nov 26, 2011 at 6:09:57 pm

"Not that I condone fascism, or any -ism for that matter. -Ism's in my opinion are not good. A person should not believe in an -ism, he should believe in himself. I quote John Lennon, "I don't believe in Beatles, I just believe in me." Good point there. After all, he was the walrus. I could be the walrus. I'd still have to bum rides off people."

"He'll keep calling me, he'll keep calling me until I come over. He'll make me feel guilty. This is uh... This is ridiculous, ok I'll go, I'll go, I'll go, I'll go, I'll go. What - I'LL GO. Shit."

"So THAT's how it is in their family... "

and finally

"Cameron has never been in love - at least, nobody's ever been in love with him. If things don't change for him, he's gonna marry the first girl he lays, and she's gonna treat him like shit, because she will have given him what he has built up in his mind as the end-all, be-all of human existence. She won't respect him, 'cause you can't respect somebody who kisses your ass. It just doesn't work."

Which I believe bears some analogy to our relationship with Apple.

Just sayin.

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 26, 2011 at 7:52:37 pm

THERE *CANNOT* BE TOO MANY BUELLER QUOTES.


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Chris Harlan
Re: Large projects
on Nov 26, 2011 at 8:23:01 pm

ROtFL


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 26, 2011 at 7:51:10 pm

CHORTLE.


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Chris Harlan
Re: Large projects
on Nov 26, 2011 at 8:14:27 pm

[Andrew Richards] "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."

Sorry, Andrew. I don't think you understand the industrial aspect of a project like this. It is a bit more complicated than you are imagining. 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. Because of a multitude of delivery variations (1-5 promo length variations, HD, SD, PAL, NTSC, and usually 6-8 different VO versions of each length version) each episode generates between ten and ninety minutes of finished rendered video (not including any of the renders to get there). A typical broadcast season is 22 episodes. Each season can add an hour or more of rendered specialty items. Most projects are multiple seasons. All of this needs to be online at all times, and, once finished, the project needs to be stored offline for--typically--six months, though sometimes longer.

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?

[Andrew Richards] "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"

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.

[Andrew Richards] "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."

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.


[Andrew Richards] "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."

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.

[Andrew Richards] "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.
"


Yeah. I thought about that a little. Frankly, though, I like a beefier boot drive in terms of size. With enough RAM and the right kind of video card, I'm not sure you get much past a faster boot. I don't notice a whole lot of sluggishness on my system. I suppose I could do it only laptop sometime, but again, I think I'd choose the space.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 26, 2011 at 8:35:26 pm

[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?"

This is where the Audition feature can be used in fcpx. One sequence, different outs per audition. Instead of switching sequences, you switch audition clips. Yeah, it's a different way of thinking. Only what changes is what is rendered.

If you dupe a project in X, it dupes render files, too. I should say that you have the option to dupe render files or not. That means 3 minutes of final rendered video, which is 5ish Gigs or so in HQ hd.


Return to posts index

Chris Harlan
Re: Large projects
on Nov 26, 2011 at 8:52:28 pm

[Jeremy Garchow] "This is where the Audition feature can be used in fcpx. One sequence, different outs per audition."

Yeah, I definately keep thinking about the audition feature and how I might apply it for my work. In this case, it would work fine if my delivery is individual files--which it often is--but not well if I need to deliver a string out. I actually think that audition's functions--if I understand them correctly--could save me much time across an entire series, so I AM interested in that. I'll pose that as a seperate question--the ins/outs, plus/minus of Audition--next time there is a lull.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 26, 2011 at 8:58:20 pm

[Chris Harlan] " In this case, it would work fine if my delivery is individual files--which it often is--but not well if I need to deliver a string out."

Copy/paste, change audition clips. Or export each movie, reimport and string out, whichever works best.

String outs shouldn't add anything much more complicated.


Return to posts index

Chris Harlan
Re: Large projects
on Nov 26, 2011 at 9:05:26 pm

[Jeremy Garchow] "Copy/paste, change audition clips. Or export each movie, reimport and string out, whichever works best.

String outs shouldn't add anything much more complicated.
"


I don't think they add anything more complicated, other than they add rendering. Your suggestions, though, are a little more complicated than what I normally do. Normally, I just create a new timeline, drop the other six timelines into that timeline, and then render out.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 26, 2011 at 9:23:29 pm

[Chris Harlan] "I don't think they add anything more complicated, other than they add rendering. Your suggestions, though, are a little more complicated than what I normally do. Normally, I just create a new timeline, drop the other six timelines into that timeline, and then render out."

I hear you. You could do that in X as well of you want. It would involve copying and pasting though, not nesting the sequences. I wish you could take compound clips from a sequence and add them to an event, then you could do just what you do in fcp7.

Using the audition method would mean you would simply copy/paste the final sequence to itself five more times, then change the auditioned clips to fit whatever order the string out needs to follow. It's a different way of thinking, but it does work.


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 26, 2011 at 8:58:40 pm

Chris Harlan on Nov 26, 2011 at 8:52:28 pm

Yeah, I definately keep thinking about the audition feature and how I might apply it for my work.


I know this is going to upset Jeremy, sorry, but I can't see how auditions are much of an advance on just stacking alternates above each other on the timeline - except that the latter is easier to keep track of, muting what you don't want (Ctrl/B) or soloing it (Ctrl/S) to taste.

Compared to this standard practice auditions feel clunky - what you want to get at is hidden away in a sub-menu rather than laid out graphically in front of you.

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

David Lawrence
Re: Large projects
on Nov 26, 2011 at 9:16:42 pm

[Jeremy Garchow] "This is where the Audition feature can be used in fcpx. One sequence, different outs per audition. Instead of switching sequences, you switch audition clips. Yeah, it's a different way of thinking. Only what changes is what is rendered."

[Simon Ubsdell] "Compared to this standard practice auditions feel clunky - what you want to get at is hidden away in a sub-menu rather than laid out graphically in front of you."

Agreed. I also don't understand how they would help if you needed to make additional editorial changes to your project based on the audition changes. How would you keep these unique instances of the project without duplicating it? And what if you don't want to switch audition clips every time you need to output?

I don't see how this workflow helps if you need to keep multiple unique versions of finished sequences always available. Am I missing something?

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 26, 2011 at 9:32:57 pm

[David Lawrence] "Agreed. I also don't understand how they would help if you needed to make additional editorial changes to your project based on the audition changes. How would you keep these unique instances of the project without duplicating it? And what if you don't want to switch audition clips every time you need to output?

I don't see how this workflow helps if you need to keep multiple unique versions of finished sequences always available. Am I missing something?"


Guys, relax. It's an alternative way to do things. Don't worry, you won't use it.

Do you guys ever version anything like Chris does? You need to make multiple versions of the exact same timeline? Like change the music, or change one logo, or change a phone number to serve a certain market? Auditions are crucial here, you don't have to use another Project, therefore you don't have to load another Project or create a whole other set of render files, which is how this conversation got started.

Yes, it is different than fcp7.

For instance, I have a project that I am working on now and it involves 12 sequences x2 for different versions that are exactly the same minus a slate and various logos and phone numbers, as well as different VO in certain areas.

In fcp7 if a change happens, I have to change 24 sequences. In FCPX, I'd change 12 and export each one twice. I would welcome that change as it helps me do my job and keep things tidy. Thats all, if it doesn't work for you, then it doesn't work for you.

Jeremy


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 26, 2011 at 11:31:29 pm

alright sure - say - Occams razor jeremy - which is better: multiple tabbed sequences as we understand them, or FCPX architecture employing gaudy auditions?

Why am I trapped in weird visual tricksy metaphors? who came up with them? how familiar were the FCPX designers with job paying workflow? how boring is that reality for them? how much do we think they care for implementing and curating an incremental skills base for a niche target market like editing?


I will now carefully quote the only thing we really do know, from a half decade FCP coding alumni called sachin argawal.

"I worked on Final Cut Pro from 2002 to 2008..

Apple doesn't care about the pro space. The pro market is too small for Apple to care about it. Instead of trying to get hundreds or even thousands of video professionals to buy new Macs, they can nail the pro-sumer market and sell to hundreds of thousands of hobbyists like me. Apple doesn't compete on features

From 2006 and 2007.. people were choosing their hardware and software based on format support, or specific features they needed. That's boring. Apple doesn't play that game.


let's... have that last line again - it refers directly to our entire industry, our livelihood, out ability to put bread on the table:

That's boring. Apple doesn't play that game.

one more time- truncating.

Apple doesn't compete on features . That's boring. Apple doesn't play that game.



Apple had the market won, and we had good ground under our feet, but it grew to bore them so they trashed it all for their own ends.

Auditions are just a tricksy thing that apple engineers came up with to please Steve Jobs at the weekly board room demo. this application is a half imovie corporate infighting mess. Larry Jordan is now flat out saying that they ignored all private feedback. He uses the direct phrase hubris.

It goes to the heart of what apple are, or are not, as a software company: Apple are not fit to generate professional software.


and sure here - let us all enjoy the last section of Sachin's post with my own rude interjections..


So... it was time to reinvent the video editor. And Final Cut Pro X really delivers there. LOOKS GREAT. FCPX isn't defined by a feature chart. It's not trying to do more than its competitors, it's doing it better. YOU GENIUSES.And once again, Final Cut Pro stands on its own. LIKE MOTION BECAUSE THAT WORKED OUT.And once again, Final Cut Pro will expand the market of video editors out there, and I'll be one of them. YOU"RE BRILLIANT.Final Cut Pro 1.0 didn't win over every Avid user, and Final Cut Pro X won't win over every Final Cut Pro user. NOT A SINGLE ONE. But they've laid the foundation for something incredible, ITS CALLED PPRO AND AVID MATEY. and I can't wait to see where it goes from here. THEY'RE SHUTTING DOWN PRO-APPS IN 36 MONTHS Congrats to all my friends on the Final Cut Pro team who shipped this incredible release! THEY OUTDID THEMSELVES BUDDY THIS IS A NEW, BRUTAL KNEE INTO THE GROIN TO THE ART AND CRAFT OF EDITING.



to you apple - to you, and your hideously self involved care for the crazy ones.







if anyone is confused - this ad means absolutely nothing.


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 4:32:43 pm

[Aindreas Gallagher] "alright sure - say - Occams razor jeremy - which is better: multiple tabbed sequences as we understand them, or FCPX architecture employing gaudy auditions?"

Oy. The razor? Again?

As I said, you don't have to work this way, you can make as many Projects as you want.

I am not trying to make FCPX work like FCP7. I am accepting 10 for what it, and what it's strengths are.
You can disagree with how they have things laid out. That's fine. There's plenty that Avid or Vegas or Windows Movie Maker that works "how you work" or "how you think". If this is the razor, so be it. I don't have a rebuttal in that sense.

But.

If you divorce yourself from the FCP7 interface for just a minute, which I know you are smart enough to do, and look at what FCPX can do in a surprisingly efficient amount if space (many audio tracks not withstanding, that's a problem). The Project and Event system is very different. The way it is setup now, switching between Projects is kinda clumsy. If Auditions help me to work faster, or have multiple timelines within the physical space of one timeline, what's the big deal? That it doesn't work like it used to? Who was it that said if you have a hammer every problem starts to look like a nail?

So, if Apple doesn't play that game as "they don't compete on features" out of boredom, what else is new? Fcp7 was hardly a modern NLE. They have never competed on features. It worked for them in the past, why change now?

Have you read some of the Avid articles and forums? I constantly here over and over that they can't change much in the interface becuase the Avid faithful will get restless and grumpy. WTF? Where does that leave a potential new customer like me? No thanks.

Apple won the market on, wait for it....price. If FCP wasn't as cheap, it would have never been a contender. This is the company that brought us DVCPro HD over FireWire. Wow! Hardly a pro solution, but boy, was it easy, cheap for the time, and fast! HD on a laptop, with one cable! Your arguments while valid, are already extremely dated. This is the way it's always been, but perhaps your perspective has changed a bit. In that same article you mention, the guy goes on to explain how excited he is to use the new FCP, and congrats to the FCP team. Weird right? Isn't that like shaking your hand while I stab you in the back?

As far as the marketing piece, yeah, it's marketing. Aren't you a promo producer? You should know how it goes.

For marketing, read this. For $99 it already "does more" than fcp7 ever will feature wise: http://www.magix.com/us/movie-edit-pro/plus/

Magic. Life moves pretty fast, if you don't stop and take a look around every once in a while, you could miss it.


Return to posts index

David Lawrence
Re: Large projects
on Nov 27, 2011 at 5:25:27 am

[Jeremy Garchow] "Guys, relax. It's an alternative way to do things. Don't worry, you won't use it."

No worries, just interested in understanding new workflows ;)

[Jeremy Garchow] "Do you guys ever version anything like Chris does? You need to make multiple versions of the exact same timeline?"

I rarely version completely identical timelines. My most recent job is a more typical scenario - two pairs of short videos, an A and B version of each video with a minor editorial change in one section. Each video is in two languages so there's four videos total.

My workflow: edit English A version, duplicate sequence, make English B version, dupe English A sequence, replace V/O with German, dupe German A sequence, edit in B video and German V/O. Simple, straightforward and typical.

I suppose in FCPX I could do two versions, English and German and use auditions to make the A/B changes. But the differences between A and B require a few edits so I'd have to compound the changes to be able audition them.

[Jeremy Garchow] "Auditions are crucial here, you don't have to use another Project, therefore you don't have to load another Project or create a whole other set of render files, which is how this conversation got started."

Sure. I see the utility of the your example, but the tradeoffs are worth discussion. It's true you change fewer sequences in your example but you give up having every version always ready at your fingertips. I don't mind doing the work to make more changes. It's billable time so I get paid to do it. The benefits of having all versions complete and ready are especially important when the client asks me to redo "German version B" a year later.

Do you really want to be going thru auditions and rebuilding a piece a year after the fact? What if you have multiple differences? At what point do you decide that a version is different enough that it warrants a new project?

Like everything in FCPX, I'm sure audition-based versioning is great for many specific uses. But I really question if giving up the flexibility of multiple sequences per project was worth it.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 4:42:58 pm

[David Lawrence] "I rarely version completely identical timelines."

Ok, then. Perhaps auditions won't work for you. For spot work, they are rather flexible. Change the slate/tag. You could do 40 spots on one timeline.

[David Lawrence] "It's true you change fewer sequences in your example but you give up having every version always ready at your fingertips."

I would disagree. It is at your fingertips, it's just wrapped in a different package. It's fine if you don't like the wrapping paper, I find that it's kinda cool and most importantly, useful. Shoot me.

[David Lawrence] "Like everything in FCPX, I'm sure audition-based versioning is great for many specific uses. But I really question if giving up the flexibility of multiple sequences per project was worth it."

Then it's quite possible that X might never work for you. It doesn't have tabbed sequences, so I look for other effiencies instead of looking for non existent tabs.

Sorry about my iTyping this morning.


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 27, 2011 at 5:46:26 pm

Jeremy Garchow

Ok, then. Perhaps auditions won't work for you. For spot work, they are rather flexible. Change the slate/tag. You could do 40 spots on one timeline.

In principle this could work but in practice this would be pretty clunky. The main reason being that you can't actually identify the contents of an audition without actually selecting it and checking it's waht you want.

There's a lot of nice cover-flow type chrome going on there but it would be much more desirable to be able to name your individual audition clips so you could see at a glance which you were trying to pick. Usually what you have to pick out in this kind of scenario is some small detail of text which you're just never going to be able to see in the audition until you load the wrong one ...

Also I would have to set up the slate/tag/clock as an audition and try and work out which was which there as well - experience tells that this would quickly lead to mistakes. It's the easiest thing in the world to get the wrong slate on the wrong spot even when you're been really disciplined about it which is why I'd have thought it was always going to be best to have each spot tidily arranged with its corresponding slate and end tag in a conventional timeline type situation rather than selecting stuff out of an audition.

In FCPX I'd still prefer to stack connected clips above each other with variants (muting as necessary) rather than use auditions because it's just quicker and less tiresome. Auditions really do feel to me like a gimmick at this point rather than a powerful new tool - though anything could change ...

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 27, 2011 at 5:58:17 pm

And of course Auditions at the moment have only one edit mode - whatever you add to the audition will change the length of the audition. Even if this is thought to be desirable as a default behaviour which I frankly can't see that it is, there should absolutely be an alternative mode that keeps the audition the same length - especially for the kind of tagging work that we're talking about here. Very tiresome to have to pre-edit your new source clip to the right length to fit the audition.

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 7:10:13 pm

[Simon Ubsdell] "And of course Auditions at the moment have only one edit mode - whatever you add to the audition will change the length of the audition. Even if this is thought to be desirable as a default behaviour which I frankly can't see that it is, there should absolutely be an alternative mode that keeps the audition the same length - especially for the kind of tagging work that we're talking about here. Very tiresome to have to pre-edit your new source clip to the right length to fit the audition."

All of the spots that I would use it for would have replaceable parts that are all the same length.

They would all be named by ISCI and all be very organized.

Perhaps yours don't work that way, to each their own.

Instead, you could make 40 sequences, and command zero back and forth to each spot. Fun.

If Auditions don't work for you, fine. It's just a suggestion. No one is right or wrong here, although you seem to think I'm wrong for some reason.

And as far as what it was designed for, multiple take auditions, it works well there too with minimal fuss. You can watch a bunch of takes of something, and the rest of the timeline simply adjusts. No reason to make more sequences, no reason to stack anything, and usually takes aren't exactly the same length, so if they ripple everything else, it is much easier than manually editing every take in, but whatever if you don't find it useful that's cool.

No, it doesn't work like fcp7.


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 27, 2011 at 7:17:29 pm

Jeremy Garchow on Nov 27, 2011 at 7:10:13 pm

If Auditions don't work for you, fine. It's just a suggestion. No one is right or wrong here, although you seem to think I'm wrong for some reason.

It's not that I couldn't get them to work, it's just that like so much else in FCPX it seem to me there's a reasonably good idea there that feels like it needs a lot more work done to get it really up to speed.

I'll shut up now - as always I do find it very illuminating to hear your ideas for integrating this stuff into your workflows and though I seem to keep arguing with you believe me a lot of what you are saying is being absorbed and processed. And wouldn't it be dull if we agreed all the time?

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 7:40:39 pm

[Simon Ubsdell] "It's not that I couldn't get them to work, it's just that like so much else in FCPX it seem to me there's a reasonably good idea there that feels like it needs a lot more work done to get it really up to speed."

No one needs to shut up, that's not the point. Chris asked about Auditions after I originally mentioned them, and I answered. It's up to everyone to find what's best or argue that they don't work if they want. Yes, the interface isn't the best quite yet, but I tell you as using it, it does work well and is easier than FCP7 in some regards in less screen real estate. It also requires a bit of a different style of thinking, which is reallyeasy to dismiss as a gimmick, or a razor, or whatever.

[Simon Ubsdell] " And wouldn't it be dull if we agreed all the time?"

Depends on whose seat you are sitting in, I guess.


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 27, 2011 at 8:09:58 pm

just out of curiosity - what do you say to simon's point about not being able to see the contents of an audition before you select it? how would you see that working with the forty endboards you mention?


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 27, 2011 at 8:32:04 pm

Wouldn't this be easier with compound clips.

I'm a relative beginner compared to you fellows and don't do this sort of thing, but if I had 40 variations of a title I'd work like this:

Complete first title, option drag up and make changes. Repeat, collapsing completed layers into compounds as I went. Once finished, break open all the smaller compounds and collapse into one compound clip. Open the compound and solo the version needed for each export.

If I needed to work on a particular version in context i.e in the main timeline, I would first compound everything above and below it, break open the main compound, mute the other compound layers and go to work.


Granted the performance might not be there at the moment.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 9:02:43 pm

[Rob Mackintosh] "Wouldn't this be easier with compound clips."

In my opinion, no.

Most of the tags (and slates actually) I personally do in After Effects. They are rendered movies, so I am just swapping movies.

Have you messed with auditions yet?


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 27, 2011 at 10:32:32 pm

Not much.

Will explore them more.

I'm coming around to your POV.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 10:40:25 pm

Compound clips will work, but auditions have "easier" capabilities in terms of viewing many takes easily and quickly.

Compounds would be a few more keystrokes, but they could work as you propose.

They are both containers, but have different functions.


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 27, 2011 at 11:16:30 pm

A container that functioned like a group in Motion - a collapsible stack - would be useful.

From memory this has been raised a few times on this forum.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 11:42:41 pm

[Rob Mackintosh] "A container that functioned like a group in Motion - a collapsible stack - would be useful.

From memory this has been raised a few times on this forum.
"


Absolutely.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 9:00:50 pm

[Aindreas Gallagher] "just out of curiosity - what do you say to simon's point about not being able to see the contents of an audition before you select it? how would you see that working with the forty endboards you mention?"

I don't really understand, really. You can see a thumbnail and a name in the audition popup, you can also skim the clip in the audition popup, then use right/left arrow to choose, or you could always the clip back to the viewer. It's pretty easy to see what's happening, in my opinion.

You set ins and outs on a clip and then add it to an audition to apply any duration you want, just like any other clip anywhere.

In the case of my 40 slates and tags, it's easy. Usually when it comes down to this amount of spots, everything is well organized by me to keep me sane. Self preservation. Every spot has an ISCI code (or SpotID) and the slate is named ISCI#_Slate and tag is ISCI#_Tag. All spy's are exactly the same length including black, slate, black, spot, black Simply match the tags/slates and I can have 40 timelines in one timeline. You do have to export one by one, but with FCPX, even if I had 40 Projects, I'd have to do that anyway.

Is that what you mean? Hope that answers it.

Jeremy


Return to posts index

Aindreas Gallagher
Re: Large projects
on Nov 27, 2011 at 9:07:38 pm

Sure, I like to name things too - it really helps in these situations, but aren't you still spooling through tiny thumblnails until you see the clip title corresponding to the Sunday evening spot endboard? They're not independently selectable items or sequences for export. They're locked into that weird audition carousel that you have to spool around one by one every time to get to the board you want. That's a little ridiculous isn't it?


http://www.ogallchoir.net
promo producer/editor.grading/motion graphics


Return to posts index

Walter Soyka
Re: Large projects
on Nov 27, 2011 at 9:28:25 pm

FCPX would really benefit from deeper metadata integration into the timeline.

It'd be pretty cool if you could tag clips in auditions and have FCPX re-edit for versioning based on your tags.

And that's just one obvious application for metadata-aware editorial. We've got some new tools -- it'd be wonderful if we could use them to solve common (and easily automated) editorial problems that weren't easily solved before.

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


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 9:48:03 pm

[Walter Soyka] "FCPX would really benefit from deeper metadata integration into the timeline."

More control!!!!!!

Indeed.


Return to posts index

Chris Harlan
Re: Large projects
on Nov 28, 2011 at 1:51:30 am

[Walter Soyka] "FCPX would really benefit from deeper metadata integration into the timeline.

It'd be pretty cool if you could tag clips in auditions and have FCPX re-edit for versioning based on your tags.

And that's just one obvious application for metadata-aware editorial. We've got some new tools -- it'd be wonderful if we could use them to solve common (and easily automated) editorial problems that weren't easily solved before."


Exactly! This is the kind of stuff I thought the FCP X's advanced metadata would be handling. I still see this as the promise, and the place that FCP X might eventually find solid industrial ground. But will it ever open up enough? Or is it going to stay as tight as, say iPhoto, with which it seems to share a number of characteristics.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 9:47:40 pm

[Aindreas Gallagher] "That's a little ridiculous isn't it?"

I guess I see it as choosing a clip. You don't have to spool through cover flow, you can just use control left/right arrow to easily blow through all the clips. They are added in order that you add them, so most likely alphabetically in the case of ISCIs as I'd drag a wad to the audition. And of course you can make audition clips in the browser.

It's either that or constantly spool 40 separate timelines. I'll say this again. If a change comes to the meat of the spot, I change one timeline, I don't have to change 40 timelines, which I like. I'll put up with having rifle through a few clips.


Return to posts index

Herb Sevush
Re: Large projects
on Nov 27, 2011 at 9:38:19 pm

Actually, as a non-user, I always thought the idea of auditions having different lengths was a major strength. It's something you can't do in FCP7, the whole stacking and muting idea only works if the clips are the same length. It would seem to me auditions would shine when you want to try out different takes of the same scene, where each take might be a few seconds off from each other, and compare how they play with the material around it. I always thought that was a great idea.

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 9:52:45 pm

Bingo, Herb. I was messing around from a current shoot where every take was a bit different. Auditions were really cool. It made it much more dynamic, it feels like trimming, but you're choosing takes. You really can get a sense of the edit and choose takes for the best of the edit much easier and faster, not to mention it's helps further the creative, but everyone knows that already. Right? Just kidding.


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 28, 2011 at 10:37:41 am

I completely agree, Herb, that there is a use for this and it is very powerful as a concept - although for me it shouldn't be the default behaviour, it should be the fancy alternative.

I was trying to make the point that there should at least be an option to do it the other way (audition duration stays the same regardless of the duration of the source clip) which would at least conform to the conventional 3-point editing standard. The audition is already an edit duration (with its own in/out) so it should normally only require one edit point in the source clip.

When I first saw it demo-ed I though it was a great idea for "auditioning" multiple cutaways - clients are always wanting to try this shot instead of that shot and then changing their minds and this would have been a perfect tool to accommodate that if they'd only given us the option for the audition to keep its length.

As it is, it's not worth the extra effort of setting a precise duration for each source clip to match the precise duration of the audition - at least in my view. It's much easier to stack the options in the old-fashioned way, until such time as Apple get around to changing this.

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 28, 2011 at 8:03:00 pm

[Simon Ubsdell] "When I first saw it demo-ed I though it was a great idea for "auditioning" multiple cutaways - clients are always wanting to try this shot instead of that shot and then changing their minds and this would have been a perfect tool to accommodate that if they'd only given us the option for the audition to keep its length. "

Are your cutaways always the same length?

If you need the clips to be the same length for timing reasons, you would find your in point "i", hit control-d then type in the length of that spot on the timeline (lets say it 3s12f) and then hit the add to audition keyboard shortcut.

So, find the frame, i, control-d, 3, 1, 2, Add to Audition.

What I find nice about it is how fast you can switch between takes, and the clips take up a lot less real-estate than stacking them all up on each other, especially if you have a bunch of good takes/variations.

The can also be stored for later for easy swapping just in case you need it. I don't know, maybe others find that confusing and would rather have everything stacked up. I can see that.


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 28, 2011 at 8:09:28 pm

Jeremy Garchow on Nov 28, 2011 at 8:03:00 pm

Are your cutaways always the same length?

Well, yes this is exactly what I am trying to convey. The most common client editing scenario is to have an edited piece with the length pretty much locked down and what they want to do is try alternative shots - the length of the new shot being determined by what's already on the timeline. Hence my plea - which will obviously go unheeded because nobody else seems to ever fact this scenario - that we could at least have an option where auditions didn't change length.

I do understand FCPX (and editing generally) to understand how to cope, however, but thanks all the same for the step-by-step instructions!

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

David Lawrence
Re: Large projects
on Nov 27, 2011 at 8:36:04 pm

[Jeremy Garchow] "I would disagree. It is at your fingertips, it's just wrapped in a different package. It's fine if you don't like the wrapping paper, I find that it's kinda cool and most importantly, useful. Shoot me. "

I don't want to shoot you, I want to help you avoid pain when a year from now your client asks you to change to one of your versions and you have to hunt thru cover flow to try reassemble it all over again ;)

But seriously, I'm happy auditions work with your versioning workflow. To each his own. I just think the tradeoffs are worth examining, especially in the context of this thread on project bloat.

We're only now starting to take in the full consequences of Apple's radical change to sequence architecture. The bloat issue is real and it's very disturbing. I sincerely hope it's a bug/implementation issue and the engineers are on top of it, but this looks like something that's pretty deep. Apple's response and how long it takes them to address it will be telling.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 27, 2011 at 9:25:41 pm

[David Lawrence] "I don't want to shoot you, I want to help you avoid pain when a year from now your client asks you to change to one of your versions and you have to hunt thru cover flow to try reassemble it all over again ;)"

That's the easy part, it's in one Project. ;)

[David Lawrence] " To each his own. I just think the tradeoffs are worth examining, especially in the context of this thread on project bloat."

Very true. Auditions would help here, I'd imagine.

[David Lawrence] "We're only now starting to take in the full consequences of Apple's radical change to sequence architecture. The bloat issue is real and it's very disturbing. I sincerely hope it's a bug/implementation issue and the engineers are on top of it, but this looks like something that's pretty deep. Apple's response and how long it takes them to address it will be telling."

It certainly is a bit disconcerting. With multicam coming, my bet is that they fix it, or get it working more efficiently. Or not.


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 26, 2011 at 9:19:03 pm

[Simon Ubsdell] "I know this is going to upset Jeremy, sorry, but I can't see how auditions are much of an advance on just stacking alternates above each other on the timeline - except that the latter is easier to keep track of, muting what you don't want (Ctrl/B) or soloing it (Ctrl/S) to taste. "

Theres no right or wrong way, just alternatives.

In Chris's case, that means having six clips stacked to each other, and setting up six different Subroles. That's fine if that's what you want. Maybe someone else might find that messy.

Or you can use an audition to keep everything tidy, and change the audition on just a few clips. It's up to you and your needs.

The workspace is currently limited in FCPX so having alternative ways to view and store your edits and choices is key. Plus, perhaps some people like the tidiness and don't need everything available in front of them if they aren't using it. To each their own, fcpx allows a few different ways, including making six different sequences if that what it takes.


Return to posts index

Andrew Richards
Re: Large projects
on Nov 26, 2011 at 9:05:12 pm

[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


Return to posts index

Rob Mackintosh
Re: Large projects
on Nov 25, 2011 at 3:04:07 am

I have had a similar experience with a 50 minute SD project. Broken into 4 separate projects to manage. See below for where 300 markers in the wrong place can get you:




Long post here: http://forums.creativecow.net/readpost/344/5732 if you want the details.

There's a lot of clever thinking gone into FCPX. I think the much maligned Randy has looked at everything from iMovie to SGO Mistika and arrived at a product design that, once you wrap your head around it, can really speed up workflows.

The execution is atrocious. How is my iTunes database file (.itl), that references 20 000 + items and 150GB of data, kept to only 6MB when my humble fcpx project referencing a few hundred items and about 8GB can balloon to 1.2GB?
(Incidentally the iTunes XML is 4x the size of the .itl database)


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 24, 2011 at 12:51:20 am

Movies are now private. :/


Return to posts index

Andrew Richards
Re: Large projects
on Nov 24, 2011 at 4:01:43 am

Reading the experiences here and via your link my hunch is the weakness is in the storage hosting the project and event databases. IOPS are critical to snappy database activity, and I suspect most editors are storing projects like media, on storage that is very big and can stream big bitrate data. That same storage, likely HDDs (even if it is RAID) will not be particularly good at serving database queries against large databases.

If anyone has an SSD in their rig, testing a large project or event on the SSD vs an HDD might yield a considerable performance gap in favor of the SSD.

Best,
Andy


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 3:12:36 pm

This seems related:

http://fcp.co/final-cut-pro/news/655-apple-made-a-64bit-final-cut-pro-8-and...

Rich is a stand-up guy, but this data point isn't really verified anywhere else. Nevertheless it gives credence to the claims that FCP X was intended as an FCE successor.

My guess is that FCP X was released in its current form with the idea of buying time to continue rewriting a more "pro" version that still fits this design. I have heard from other folks close to third party developers about two versions in development. Might be BS or might be part of the same rumors. In any case, no matter how skilled we think the Apple coders are or aren't, it takes time to make the sort of about-face that they had to do.

Plus, the OS team is equally compartmentalized. Since FCP X is so tied to components in the OS (unlike Avid or Adobe), there are certain things FCP X simply can't do until that portion of the OS is ready for the FCP X team. All of this leads us to a lot of anticipation for the Q1 2012 update. If that doesn't show significant core improvements beyond just multicam and broadcast output, then we'll know Apple isn't all that interested in our world anymore.

Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 4:22:49 pm

[Oliver Peters] "Rich is a stand-up guy, but this data point isn't really verified anywhere else. Nevertheless it gives credence to the claims that FCP X was intended as an FCE successor."

One of Philip Hodgetts' recent podcasts (I forget which one) put forward the idea that FCP7 was going to be the 64-bit FCP, but Apple's about-face on 64-bit Carbon scuttled that. The FCP team were supposedly forced to start over and took it as an opportunity to really start over. Richard's aside about there being a 64-bit FCP they had to abandon (regardless of version number) aligns with that.

[Oliver Peters] "My guess is that FCP X was released in its current form with the idea of buying time to continue rewriting a more "pro" version that still fits this design. I have heard from other folks close to third party developers about two versions in development. Might be BS or might be part of the same rumors. In any case, no matter how skilled we think the Apple coders are or aren't, it takes time to make the sort of about-face that they had to do."

Maybe at some point prior to FCPX's release there were two products in the pipeline, but I'd be pretty surprised to see something beyond FCPX coming down the pike. Maybe they merged the products and the heavy duty stuff is what is being added in incrementally. With all the NDA sidestepping any of this info would need to navigate to get to us, there is plenty of room for a lot of truth, even if the details are muddy.

[Oliver Peters] "Plus, the OS team is equally compartmentalized. Since FCP X is so tied to components in the OS (unlike Avid or Adobe), there are certain things FCP X simply can't do until that portion of the OS is ready for the FCP X team. All of this leads us to a lot of anticipation for the Q1 2012 update. If that doesn't show significant core improvements beyond just multicam and broadcast output, then we'll know Apple isn't all that interested in our world anymore."

This is a very important point. I'll bet you a fiver that broadcast I/O absolutely depends on a new API in Lion (CoreMediaIO). I really hope we get a successor to the cheese grater Mac Pro to go with it. The hardware is a bigger indicator for where Apple wants to be- that is where they make their money. Software isn't a profit center.

Best,
Andy


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 4:28:51 pm

[Andrew Richards] "Maybe at some point prior to FCPX's release there were two products in the pipeline, but I'd be pretty surprised to see something beyond FCPX coming down the pike. Maybe they merged the products and the heavy duty stuff is what is being added in incrementally. "

That's what I meant and not that we'd eventually see two products. I think the capabilities will get ramped up, but still within this magnetic/trackless/metadata paradigm.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Andrew Richards
Re: Large projects
on Nov 25, 2011 at 4:35:03 pm

[Oliver Peters] "That's what I meant and not that we'd eventually see two products. I think the capabilities will get ramped up, but still within this magnetic/trackless/metadata paradigm."

Agree. I hope the practical shortcomings of the magnetic timeline are being addressed in parallel to the spec sheet upgrades that are coming. They really need to let you explode audio tracks out from a clip for manipulation without detaching them and risking sync loss, for one thing. Role-based mixing would be handy too, though it is probably be easier said than done.

Best,
Andy


Return to posts index

Chris Harlan
Re: Large projects
on Nov 25, 2011 at 9:13:34 pm

[Andrew Richards] "Role-based mixing would be handy too, though it is probably be easier said than done."

Yeah. If I could patch Roles to a mixer--and color code them by type--I'd be happy, I do believe.


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 9:18:16 pm

Aside from large projects, it's stunning at just how slow the UI is in general. Forget skimming and look at some of the basics.

I'm working on a small project. 80 ProResLT clips marked as favorites and rejects. Event is set to list view and show only favorites. The action to twirl down the disclosure triangle takes about 1 sec. It's a simple 2 min. timeline of about 35 clips. Rearranging the order of the clips in the magnetic timeline takes about 1 sec. or more for the timeline display to redraw while making the insert. Drag a clip over another to replace and it takes 1-2 sec. for the replace dialogue to appear.

This is using an 8-core MP, 12GB RAM, ATI 5870 card. Mac OS 10.7.2. The media is on a 2-drive RAID-0 internal pair of 7200RPM drives. FCP X responsiveness compared with FCP 7 (or just about any other NLE) is just sluggish.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Steve Connor
Re: Large projects
on Nov 25, 2011 at 9:42:11 pm

I don't believe FCPX works as well under Lion as it does on Snow Leopard, certainly on my system there is less lag on actions and it doesn't get bogged down on memory leakage as much

"My Name is Steve and I'm an FCPX user"


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 25, 2011 at 9:50:21 pm

That's even worse news - I haven't made the move to Lion yet, I'm still on SL and it's got major issues!

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 9:57:08 pm

[Simon Ubsdell] "That's even worse news"

Ironically FCP 7 feels like it's working better under Lion. At least it appears to render faster.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Simon Ubsdell
Re: Large projects
on Nov 25, 2011 at 10:39:17 pm

Oliver Peters on Nov 25, 2011 at 9:57:08 pm

Ironically FCP 7 feels like it's working better under Lion. At least it appears to render faster.


Thanks for the heads-up - sounds like it's maybe time to make the move.

Simon Ubsdell
Director/Editor/Writer
http://www.tokyo-uk.com


Return to posts index

David Lawrence
Re: Large projects
on Nov 25, 2011 at 10:24:20 pm

[Oliver Peters] "it's stunning at just how slow the UI is in general. "

Some of the UI sluggishness seems to come directly from the animation effects, heavily used throughout the UI. Animation by its very nature takes time, so even if the system is responding instantly, time must be used to display the animation.

Just one example - when pressing arrow keys to go to next/previous edit, the cursor sliiiides to the next edit point. It takes a second.

Contrast this with Avid MC -- next/previous edit, even stepping in and out happens instantly. The UI feels responsive because as much as possible, it displays the results of the user's action as quickly as possible. This is UI 101.

I have to sincerely ask -- what is the professional justification for fancy FCPX animation? Outside a Core Animation demo, what practical purpose does it serve? It is completely inappropriate in a professional application, and at the very least, there should be a preference to turn it off.

_______________________
David Lawrence
art~media~design~research
propaganda.com
publicmattersgroup.com
facebook.com/dlawrence
twitter.com/dhl


Return to posts index

Oliver Peters
Re: Large projects
on Nov 25, 2011 at 10:39:45 pm

[David Lawrence] "Some of the UI sluggishness seems to come directly from the animation effects, heavily used throughout the UI. Animation by its very nature takes time, so even if the system is responding instantly, time must be used to display the animation."

I completely agree. There should be a preference to turn off all animations. This is possible in Lion in general or via tweaking utilities. The default should be OFF.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

T. Payton
Re: Large projects
on Nov 26, 2011 at 7:39:54 am

[David Lawrence] "Just one example - when pressing arrow keys to go to next/previous edit, the cursor sliiiides to the next edit point. It takes a second."

[David Lawrence] "Contrast this with Avid MC -- next/previous edit, even stepping in and out happens instantly."

After examining this carefully, the viewer actually changes to the next edit and then the animation completes. So it is ironic that those animations might now actually slow down editing, it sure makes it feel and look like it is moving slowly.

I actually feel that some of the animations are appropriate. Specifically on ripple and roll edits. They give you excellent visual feedback on what your edit is actually doing.

I stil would vote for a preference to minimize animations.

------
T. Payton
OneCreative, Albuquerque


Return to posts index

T. Payton
Re: Large projects
on Nov 26, 2011 at 7:57:57 am

Correction from my last post:

"it is ironic that those animations might NOT actually slow down editing, but it sure makes it feel and look like it is moving slowly."

------
T. Payton
OneCreative, Albuquerque


Return to posts index

T. Payton
Re: Large projects
on Nov 26, 2011 at 7:53:39 am

I believe the two products references are just tracks of code bases as a practical method of software development. They have one with code base "B" containing the development of multitrack and broadcast monitor out, while they have another code base "A" with the current version and any incremental fixes needed, like the 10.0.2 update we just received. "A" is just getting a few patches as needed, while the real work is being done in "B'

We can only hope someone in the FCP group is reading our posts and wishes they could tell us that "B" fixes alot of these DB issues.

Therefore:

"Dear FCP Group Member, please throw us a bone. Or leak through a rumor site or two of the existence of a bone fix to the project file problem. It would give us some hope!"

------
T. Payton
OneCreative, Albuquerque


Return to posts index

Andreas Kiel
Re: Large projects
on Nov 26, 2011 at 1:19:42 pm

some notes regarding FCPXML vs FCP 7 XML.

FCPXML at the moment is a very basic thing. most of the parameters (and metadata) are not transported into the XML. so it is obvious that the xml is very small compared to the project. so it does not make to much sense to compare project and XML.
another thing is that if you look at the XML it is still connected to the original event (by the uuid) this allows the eco system to refer to the project where the XML came from even though it creates a copy of the project.
This can be good or bad. with legacy XML versions people like me where able to change references and parameters. this is not possible at the moment with this version of FCPXML. as many of the parameters are not listed in the new XML type, much of those stuff you might have changed is gone - means you never got a real copy of the clips parameters, effects etc. but everything which is related to the project itself is kept by reference to the original project.
the marker stuff is interesting, i have not tried that, but definively will have a look.

andreas - and i hate typing on the ipad

Spherico
http://www.spherico.com/filmtools


Return to posts index

T. Payton
Re: Large projects
on Nov 30, 2011 at 3:48:10 pm

Regarding the original post and the "Foozball" search issue, turns out the Search Box in the event browser ONLY searches for names of clips and their notes, not keywords.

I confirmed this on page 101 of "Apple Pro Training Series: Final Cut Pro X".



I couldn't find this in the online help, but the above training is the closest manual there is at the time.

------
T. Payton
OneCreative, Albuquerque


Return to posts index

T. Payton
Re: Large projects
on Nov 30, 2011 at 3:57:00 pm

Found the reference in the FCP X help here:

http://help.apple.com/finalcutpro/mac/10.0.1/#ver65764b45



------
T. Payton
OneCreative, Albuquerque


Return to posts index

Jeremy Garchow
Re: Large projects
on Nov 30, 2011 at 4:24:32 pm

[Timothy Payton] "ONLY searches for names of clips and their notes, not keywords. "

Great point, Timothy.

It also doesn't search for the names of Favorites (if you name them), but it does have marker search capability. Almost all other metadata in the huge mass that FCPX allows, is also not searchable in the Browser which seems odd, but perhaps it's a performance issue as we are experiencing.


Return to posts index

T. Payton
Re: Large projects
on Dec 6, 2011 at 9:32:39 pm

Just a followup on the large project problem in this thread. http://forums.creativecow.net/readpost/335/21413

I finally made it to my local Apple store to try this on some new 2011 27" iMacs. The slowdowns were almost identical to my 2006 MacPro (13GB Ram), or my 2007 MacBook Pro (4 GB Ram). However, they all had 4 GB of RAM, but FCP X was only using a little of 1 gig most of the time. One of the employees I was showing this to with was floored at the slow performance, especially when typing text in a title on a somewhat complicated project. I was trying to reassure him that the rest of the app is excellent, it is just the database format that is the problem.

I also mentioned to him that despite the slowdowns, the more efficient workflow in FCP X is actually breaking even in my edit time as compared to FCP 7. I have found several workarounds, and right now FCP X is working really, really well for the projects on my plate.

The fact that the performance on my projects was so bad on the new iMacs actually made me very hopeful. I was thinking that my old MacPro workhorse was needing to be abandoned, but my MacPro isn't the problem, but rather that database method in FCP X!

I would encourage all of us who like FCP X to give Apple a call or Send Feedback to make the FCP team to let them know how aware we are of the problem we have discussed here and that it is essential that they fix it.

------
T. Payton
OneCreative, Albuquerque


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]