Very slow response when typing in titles

I was having the same problem. I was running the Viewer on a second display. On a hunch, I switched Revert to Original Layout/one monitor and performance improved dramatically.

The other thing I've found is that it is better/faster to type titles in the viewer instead of the inspector.

Hopefully you find the same performance increase I did.

I spend almost my entire day on researching my problems. Lots of spinning beach balls, like in the TED movie. I am not very happy with my findings

- Compound clips are definitely the problem of the large event files and slowdowns I am experiencing
- Harddisk are continuously being read while dealing with compound clips, while CPU and RAM remain almost unused
- When I move the compound clips out of the event to a new event, the project size is still 540MB (was 640MB)
So around 20 compound clips use 540MB of storage
- When you do a multi-select on all the compound clips, the application freezes, because it tries to load them all at the same time before they get selected

I did two things:

1. move all the compound clips to a new event, event size changed from 640mb to 540mb (so compound clips are the source of evil)
- after I closed FCPX and re-opened, this new event crashed the application
2. delete all the compound clips from the event, event size remained 640mb

This conforms my earlier suspections: if you delete compound clips, markers or metadata, .fcpevent files never shrink in size. This means that if you work on a project for a long time, and make lots of changes and temporary compound clips, you have a problem.

I am not sure if having 20 events instead of 1 helps as it needs to load all 20 events which might also tax the system. I have to try that.

My conclusion is that I am now stuck with an event in which I put like 40 hours of metadata entry and there is no way to 'tame' it to a normal file size. From now on, I won't use a single compound clip anymore till Apple fixes this. If Apple sees this as normal behavior I might even consider switching to another editing application as I see the solution with all the small projects more like a hack and not a fix. I hope the FCP team really finds a way to stop creating these huge project and event files. I will experiment the coming weeks with moving all compound clips to separate projects and see how that goes (only way to manage my bloated project).

Of course this could also be a corrupt event or something. Similar experiences out there? I am talking 20 - 30 compound clips in 1 event.

There is something wrong here:

"- When I move the compound clips out of the event to a new event, the project size is still 540MB (was 640MB)
So around 20 compound clips use 540MB of storage"

This doesn't make sense. How do you arrive at 20 compounds use 540MB. It looks like 20 compounds use 100MB.

What's the TED movie?

sohus wrote: - Compound clips are definitely the problem of the large event files and slowdowns I am experiencing

If you delete compound clips, markers or metadata, .fcpevent files never shrink in size. This means that if you work on a project for a long time, and make lots of changes and temporary compound clips, you have a problem.

I've had large event files that don't have compound clips that are still slow. My suspicion is that compound clips by their nature are not the problem, but when they are used like a clip they are a problem. i.e. when they have lots of markers, keywords, etc. and used multiple times in a timeline. It's a recipe for disaster.

Regarding the currentversion files not shrinking after deleting, in my testing I've found it will strink once you quit the app and restart it. Sometimes it takes a couple of times. I'm suspecting there is an "undo" cue still in the DB file that isn't wiped out until a restart of the app.

BTW. Apple is aware of this problem, but I would definitely take all your feedback and submit it on a FCP feedback form. I've been encourage by Apple to encourage others to do this on this very problem - they need to know how it is effecting other users and sincerely do read all those FCP feedback forms.

Concerning your real project that has a bunch of compound clips: Are these synchronized clips with a whole bunch of markers, favorites and keywords by any chance? How are you using these on the timeline? Are you seeing slowdown in the event itself or only when you start editing on a timeline?

Many people are reporting that Lion is a serious slowdown bottleneck, and that the same or similar projects give much better performance in Snow Leopard.

Tom Wolsky wrote: There is something wrong here:

"- When I move the compound clips out of the event to a new event, the project size is still 540MB (was 640MB)
So around 20 compound clips use 540MB of storage"

This doesn't make sense. How do you arrive at 20 compounds use 540MB. It looks like 20 compounds use 100MB.

What's the TED movie?

I made a mistake in my statement:

If I move the compound clips out of the event to a new event, they take in 540mb. This means that the metadata library is roughly 100mb. So compound clips are huge.

When you work on a large project, it might seem logical to put all the media into one event. From my experience, I think it is better to split your footage by the day event, like a real event, and switch between events while editing. It would be nice if you could have sub-events or something or even folders.

From what I have learned so far, I think compound clips should be avoided until Apple fixes stuff. No matter if you are editing in them or only copying projects in them. The better way to work right now is with projects. Just create a project folder with your project name and do all the versioning and (nested)sequences into separate project files. This also reduces the chance that your project/event becomes corrupted.

Interesting that Snow Leopard users seem to have less problems. Haven't heard about that.

And yes, I do submit feedback forms all the time. Only thing I really hate is that I never hear anything from them, but that's also what they state so I shouldn't complain.