General Lag, Waveform Showstopper

[Jeremy Garchow]

Is your library on the SAN too?

[Chris Frantz]

They are stored locally. All leave in place media.

[Jeremy Garchow]

There is definitely a lag on long clips. Once the waveform is drawn, it does speed up.

Cache off of the SAN is definitely the way to go. A fast SSD is a great place to dump it.

Waveform and thumbnail drawing has always seemed to be a slow point with fcpx. Sometimes, I trash them all and start over and that helps a ton, but it takes a while. The performance has been getting better with every update, but I still have issues when going in to the audio components in the inspector on long clips as I have to wait for those to draw.

Please report this to Apple.

Jeremy

[Chris Frantz]

I have reported it to them in different ways a few times and haven’t heard anything back. I don’t expect to either without an enterprise contract. This is a crippling bug that knocks this NLE out of the running for any long-form TV.

[Jeremy Garchow]

When you first import a movie, you’ll notice the little render wheel spinning in the middle. If you quit X before that is done, you’ll get a warning about Processes not being complete, and if you quit now, they won’t complete. I find it’s best to leave X running until that wheel stops spinning.

I clean thumbnails (not peaks data) often, and even with the rebuilding time, X seems to perfom better, especially if you move libraries and caches around to different machines.

Keep reporting to apple, and keep caches local.

[Charlie Austin]

Also, and you may already do this, turn off any type of audio analysis in the import prefs, including “group stereo separate mono”.

————————————————————-

~ My FCPX Babbling blog ~
~”It is a poor craftsman who blames his tools.”~
~”The function you just attempted is not yet implemented”~

[Chris Frantz]

All audio analysis is off in the preferences. The odd thing is that it seems to draw for a few seconds, then hang, then when you force quit the beachball, it will come back with a few of the waveforms partially drawn. Then you zoom in one step, and they disappear entirely, even you zoom back out another step. On top of all that, FCPX by default will draw waveforms in the inspector, event browser, and the timeline. These seem to be independent of each other. And because of the way it displays audio, it draws a mix down of however many audio channels to display as the general audio track. On top of all of that, the only place you can zoom in and interact with the waveforms is in the timeline.

So it’s doing all of the extra lifting for nothing and still not letting us use the program without letting it digest a 52 minute file for 15 or 20 minutes. How is this not the biggest problem with FCPX? IMO it contributes to massive program lag, cache bloat, and general system performance. Apple are you there?

[Bill Davis]

In general, two things I’ve come to accept about X is A) it’s constructed around high precision calculations. And B. That default construction concept is very much a double edge sword. That it can accept DV25, iPhone, H-264 (dslr) and RED Epic all into a single timeline is great. As are its sub-frame audio editing capabilities. These are great benefits. But they also imply a program that has to apply high precision uncompromising math to some exceptionally large data sets. I suspect that with audio waveforms, generating a database of very precise pictures of potentially billions of samples in an hour program takes some serious grunt. And X can fool users since its “instant get to work on import” seems to happen like magic. The thing is that, as Jeremy and Charlie imply, if you never give X the chance to complete calculating the waveform image caches, but keep shutting down impatiently, you may be inadvertently making things worse, not better. This also presumes the source audio matches your project settings so you’re not asking X to transcode AND draw its high rez audio waveforms simultaneously. Seriously,so many worldwide users from network tv to film and beyond now use X daily, that there is surely a solution to this. My suspicion is that the nature of the audio coming in and the project settings might be mismatched. I say this because I’ve imported plenty of 60 and 90 min content and gotten right to work. Yes, sometimes it takes overnight to let the audio (or sometimes the video!) to complete processing under the hood. Or I might have to force it for export and be patient for export. But the system always gets the work done if I let it, and typically way faster overall than before I switched to X. Good luck.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com – video editing curriculum complete with licensed practice content.

[Chris Frantz]

Wait you’re kiddibg, you’re waiting overnight to start working because of waveform rendering? How do you bill your client for that wasted day? I can take these same files into FCP7 and Premiere, with the same sequence settings and they work fine. I’m able to get to work right away. I’m not the only one with this issue. For the record, premiere also can do sub frame audio editing and can also import plenty of different types of footage. Again, FCP7 handles these prores files delivered for broadcast just fine.

[Jeremy Garchow]

I agree that this is a problem. Waverorms and cache always has been in X. It used to be a problem on all files, and there would be many more beach balls. This has obviously been worked on by Apple becuase it gets better and better. Now, it seems to be long files that have the most problems.

And as Bill says, letting it sit before quitting seems to help. I don’t wait overnight, that would be impractical. I keep working.

I would also, just for yuks, copy one of the offending files to local storage. Make two libraries. Import the one copy from local, and one from the SAN and note any performance difference.