[T. Payton]

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

[T. Payton]

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

[T. Payton]

[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

[T. Payton]

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

[T. Payton]

[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

[T. Payton]

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.”

https://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

[T. Payton]

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

[T. Payton]

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: https://www.youtube.com/watch?v=bRIeTZ-RNzc and here: https://www.youtube.com/watch?v=_DEviM0eScU

– 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

[T. Payton]

Besides just looking at the file. It’s very readable.

Also you can look here:

https://developer.apple.com/library/mac/#documentation/FinalCutProX/Reference/FinalCutProXXMLFormat/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011227-CH1-SW1

——
T. Payton
OneCreative, Albuquerque

[T. Payton]

Rob – great points.

I’m purely speculating, but from the looks of it even a very complex edit with many nesting compound clip with lots of markers the project file doesn’t need to be that large.

I have a feature length project, about 2500 edits, and while the project file is 96MB, the FCPXML is just 2 MB. What in the world is in the other 94MB in the project file?

I think it is interesting now that having used FCP X for a while, I appreciate the incredible simplicity that they have introduced in the App. I was thinking about locking tracks and track targets the other day and the hoops I had to jump through to get a few simple edits done. It is funny now, that I realized many of the objections I had initially with FCP X are really areas where I wanted to be able to jump through the hoops that I had to jump through in FCP 7.

The entire main storyline always in ripple mode is brilliant! Trackless editing is brilliant. The fact that at a glance we can see the audio level of any clip is amazing. The “throw any format on the timeline and it will work” is incredible. The Proxy workflow is amazing. I could go on.

It’s very much akin to when Apple recreated the smart phone and removing all the buttons in the iPhone except one — they simplified things to the point of brilliance. I tried to help someone with their Nokia phone the other day, and was amazed at how difficult it was to use with all those buttons.

However…. the problem is not with the radicalness of FCP X concept, but the execution. I know this isn’t the case but I picture in my mind the FCP X team made up of just a handful of people that are completely overwhelmed and unable to get anything but the most basic fixes done. The bug list has to be huge! I have been keeping a record of the bugs, and I have sent over 50 to Apple. 50 bugs that just one user has seen on a shipping product! That is crazy! In all my years beta testing I have never been able to report 50 bugs on a beta. This is just not a thoroughly executed program on the programming level.

Hopefully Apple will be creating a professional beta program so that actual users will be giving feedback to the product. If Apple would just devote the resources… and they have the resources… then FCP X would be executed wonderfully just as it was designed to be.

——
T. Payton
OneCreative, Albuquerque