10.3 issues

Tom Wolsky wrote: FCP 7 could never do that. Not close. That's bullshit.

Oh I betcha it could come pretty close. Regardless, that XML isn't the only thing that shows the problem anyway. FCPX has been laggy for me since it's inception. I know you want to believe that FCPX is 100% perfect, but it's not. The truth is I can do long form complex editing in FCP7 and doing the SAME EXACT EDIT in FCPX shows noticeable lag. Not as bad as the uploaded XML, but much much more than FCP7 (which never shows ANY lag ever). This is why I can't use FCPX to edit my show, I can only use it for short form stuff, usually 15 minutes or less. Everything else I'm forced to still use FCP7. I have tried to make the switch countless times, but the performance of the app is the main reason I can't. I'm totally used to using FCPX and I prefer many of its features so that is not the culprit. FCP7 is just snappier and allows me to work faster without interfering with my workflow due to bad coding.

It's easy to blame the editor or the particular computer. But the truth is that FCPX should not require being run on a computer with a fresh install with only a few other apps installed. It should allow the editor to tell his or her story any way he or she prefers to use FCPX to tell it. FCPX itself should not be the limiting factor. But some folks here seem to feel that people are using it wrong or have poorly set up computers etc etc the excuses never end.

It's 2016. Why are we using an app that feels like it was coded in 2003 that's nowhere near as snappy as it's predecessor? I've edited 4K 60fps shows in FCP7 that were nearly 40 minutes long. The DESIGN of FCPX is awesome. The coding of many aspects of it leaves something to be desired. With current technology, that uploaded XML file CAN be made to work just fine if the app was coded to handle everything properly.

Exactly my argument, why am I "forced" to downgrade to get my work done. Where is the problem?

Is the problem hardware? If yes, what hardware?
Is the problem software? If yes what software?

As explained in numerous replies, the problem is not hardware, maybe to a very tiny degree, the problem from hardware is way too small to be a consideration at this point.

So what is left? Software!! It has to be one of the following...

1-Sierra
2-FCPX
3-Sierra+FCPX 10.2.3
4-Sierra and FCPX 10.3
5-Yosemite and FCPX 10.3

I would suggest it is option 3 or 4, both, the base operating system and the app are buggy, as proved in my case, a downgrade removed all issues, re-installing back to Sierra and FCPX 10.2.3 and 10.3 introduced errors yet going back to Yosemite and 10.2.3, no errors.

As 10.3 is incompatible with Yosemite, option 5 is not an option, so logically even a 3 year old can see a logic that is Sierra and 10.2.3/10.3 as 10.3 is not a new code, but a patch of old code.

As I see it, the really only viable option Apple has left is to remove FCPX from the App Store, kill any future development of 10.3, and release in a year FCPX 11, there is no other option, patching does not work, 10.3 is a patch job, a badly coded example, maybe as bad as 10.0.0.

I agree fcp7 is old, but it was pretty much bullet proof, sure it had a few minor issues, but it worked, and works now from Tiger to Sierra, that says something about the code used, the decision to delete FCP8, looking back a bad decision, 10.2 series was ok until Sierra was launched, then FCPX broke, the lines on the timecode window, never patched, why???????

The simple fact is, Sierra and FCPX 10.3 are as the British say "not fit for purpose"

Redifer wrote:

Tom Wolsky wrote: FCP 7 could never do that. Not close. That's bullshit.

Oh I betcha it could come pretty close. Regardless, that XML isn't the only thing that shows the problem anyway. FCPX has been laggy for me since it's inception. I know you want to believe that FCPX is 100% perfect, but it's not. The truth is I can do long form complex editing in FCP7 and doing the SAME EXACT EDIT in FCPX shows noticeable lag. Not as bad as the uploaded XML, but much much more than FCP7 (which never shows ANY lag ever). This is why I can't use FCPX to edit my show, I can only use it for short form stuff, usually 15 minutes or less. Everything else I'm forced to still use FCP7. I have tried to make the switch countless times, but the performance of the app is the main reason I can't. I'm totally used to using FCPX and I prefer many of its features so that is not the culprit. FCP7 is just snappier and allows me to work faster without interfering with my workflow due to bad coding.

It's easy to blame the editor or the particular computer. But the truth is that FCPX should not require being run on a computer with a fresh install with only a few other apps installed. It should allow the editor to tell his or her story any way he or she prefers to use FCPX to tell it. FCPX itself should not be the limiting factor. But some folks here seem to feel that people are using it wrong or have poorly set up computers etc etc the excuses never end.

It's 2016. Why are we using an app that feels like it was coded in 2003 that's nowhere near as snappy as it's predecessor? I've edited 4K 60fps shows in FCP7 that were nearly 40 minutes long. The DESIGN of FCPX is awesome. The coding of many aspects of it leaves something to be desired. With current technology, that uploaded XML file CAN be made to work just fine if the app was coded to handle everything properly.

I hate to say it, but I think Redifer is right. As much as I want FCPX to be the go to app for editing, I just can’t recommend it for long format productions. At least not at this point.

Feature wise the app is so cool and light years ahead of both Premiere and Media Composer. But performance is not something one can count on when editing a show more than 25 to 30 minutes long. Especially not with lots of multicam and lots of items in the timeline.

Here are two more XMLs for you all to try out. 40 min long timelines with lots of multicam and lots of items. SERIOUS DRAG LAG:

XML 1 & 2 (zipped)
dl.dropboxusercontent.com/u/55798687/XML%20FCPX.zip

Please try them out on different machines and provide some feedback.

Please fix this Apple. FCPX has the GREATEST POTENTIAL OF ALL THE NLE’S

Hey Mikael,

I have tested your XMLs, thank you for sending these to me yesterday. Actually, your projects are very similar to the project Chris has posted, and the timelines are practically the same. You are both in Denmark, is it possible that you work for the same company?

As I replied in my e-mail to you, we are trying to figure out why this particular type of project is laggy, which is obviously an issue, while we don't see anything like this on other timelines that are much longer and with many more clips. I'm sure you will get more feedback on this soon.

As to the latest comments in general:

I think we should be very careful about launching bold general statements based on a very particular issue.

No-one can deny that these projects, which actually are all of the same type, show drag-lag. But going from there to pretending that FCP X cannot handle long or complex timelines in general is not only false, it is simply ridiculous. Especially since so many big long-form productions have been cut, and are being cut on FCP X every day, without showing this particular issue. So I think it's much wiser and much more effective to try and find out why FCP X has issues with this type of project, while other types of long-form projects obviously show no problems at all.

I agree that FCP X has the greatest potential of all NLEs. And it's good to report issues related to specific workflows, because this can only make the application even better. If we see that this is something that the FCP X team needs to take care of, I am sure they will do this.

Chris and Mikael, I will get back to you with some more questions so we can get to the root of this.

- Ronny

ronny courtens wrote: Hey Mikael,

I have tested your XMLs, thank you for sending these to me yesterday. Actually, your projects are very similar to the project Chris has posted, and the timelines are practically the same. You are both in Denmark, is it possible that you work for the same company?

As I replied in my e-mail to you, we are trying to figure out why this particular type of project is laggy, which is obviously an issue, while we don't see anything like this on other timelines that are much longer and with many more clips. I'm sure you will get more feedback on this soon.

As to the latest comments in general:

I think we should be very careful about launching bold general statements based on a very particular issue.

No-one can deny that these projects, which actually are all of the same type, show drag-lag. But going from there to pretending that FCP X cannot handle long or complex timelines in general is not only false, it is simply ridiculous. Especially since so many big long-form productions have been cut, and are being cut on FCP X every day, without showing this particular issue. So I think it's much wiser and much more effective to try and find out why FCP X has issues with this type of project, while other types of long-form projects obviously show no problems at all.

I agree that FCP X has the greatest potential of all NLEs. And it's good to report issues related to specific workflows, because this can only make the application even better. If we see that this is something that the FCP X team needs to take care of, I am sure they will do this.

Chris and Mikael, I will get back to you with some more questions so we can get to the root of this.

- Ronny

Ronny

You're right. It is ridiculous to make bold statements and I may be guilty of making one or two in my last post.

I just TRULY HOPE that Apple will fix this because FCPX is a pure joy to work with when things are smooth.

All the best from here..

I totally understand how frustrating it can be to experience this kind of lag during your work. And it's very human that this frustration can lead to cursing the application, or the world in general. Believe me, I have been through such moments many times in my life working with every kind of NLE.

It's undeniable that this is a problem, and that it is related to a very specific type of work. That's why we need to get to the bottom of this, and I will pull every string I can to do so. Actually I'm very grateful that Chris and you have taken the time to report this problem. If we can help you to handle this type of complex timelines without any performance issues, it will be another win for FCP X.

- Ronny

Hi, i'm Pawel and this is my firrst post. At the beginning sorry for my English, I'm learning
Drag lad is caused by the amount of cuts on timeline not the lenght of timeline.

I did a simple test:
I put on timeline about 7 minutes clip from Canon 5d and cut it into 993 parts by using cmd + B. It was enough to show drag lag like this one: vimeo.com/192641847
After multiply entire timeline by copying clips four times drag lag is bigger. I can play timeline but editing, moving clips take long, long time. Only 160 items on timeline give me smooth workflow.

You're also on older hardware.

I'm expecting the FCPX dev team to be releasing a bug fix update soon. I'm sure they're very aware of the bugs, IF you all have been filling out the feedback page. As I recall, every major upgrade release has its share of bugs. And every one is followed by a bug fix update or two. Not just for FCPX, but for any app or OS. And if you think FCPX is buggy, have you tried PPro lately? I have...

But it is very important to fill out that feedback page PROPERLY. Provide DETAILS, hardware, OS, everything. Is the issue project specific, event specific, library specific, or not? That feedback page is vital to getting a bug fix update as soon as is possible.

Bashing gets us nowhere. Let's stick to the facts of specific issues, work through them, and report them to Apple ASAP as individuals.

MsJustine wrote:
The simple fact is, Sierra and FCPX 10.3 are as the British say "not fit for purpose"

The only problem with your ‘fact’ is it isn’t a fact at all.

While it may be true that you specifically are having an issue, not all users are experiencing the same problems.

Indeed there are some bugs to be squashed and problems solved. But some of the problems experienced by some users overall doesn’t seem to be universal in scope. The proof is many users are using 10.3 with Sierra and El Capitan with very good results overall. 10.3 is in no way the total failure you portray it to be.

Additionally, why is it that you must roll back to Yosemite? What about El Capitan? Why are you skipping or not including an entire OS version cycle your possible options?

Perhaps we all could be just a bit patient while Apple works on ironing out the wrinkles. Many times issues don't become apparent until after the initial release and adoption due to all the various potential combinations of hardware, plugins and system components. I'm sure Apple will respond in short order as they flesh out these issues and receive this valuable feedback from users.

It is a fact for me, Sierra+10.2.3/10.3 does not work, that it is not a fact for you is irrelevant, it does not work for me, that is a problem both for me and for Apple.

What you say? We all waited almost a full year and we got 10.3 and all her bugs, yay for waiting!!!

Why not try El Cap, simply I do not trust it, Yosemite and 10.2.3 works, the more recent the OS, the more unstable it seems to become. I would prefer to go even further back, but 10.2 might not work, sort of stuck at this point.

Apple if you say are ironing out the bugs, took forever to update 10.2.3, just a small patch to fix the lines and misplaced names of hours min frames etc, which has not been patched, just forgotten, so I guess waiting for something to not happen?

Why has Apple not patched the lines in the timecode window???

ronny courtens wrote: Hey Mikael,

As to the latest comments in general:

I think we should be very careful about launching bold general statements based on a very particular issue.

No-one can deny that these projects, which actually are all of the same type, show drag-lag. But going from there to pretending that FCP X cannot handle long or complex timelines in general is not only false, it is simply ridiculous. Especially since so many big long-form productions have been cut, and are being cut on FCP X every day, without showing this particular issue. So I think it's much wiser and much more effective to try and find out why FCP X has issues with this type of project, while other types of long-form projects obviously show no problems at all.

I agree that FCP X has the greatest potential of all NLEs. And it's good to report issues related to specific workflows, because this can only make the application even better. If we see that this is something that the FCP X team needs to take care of, I am sure they will do this.

Chris and Mikael, I will get back to you with some more questions so we can get to the root of this.

- Ronny

Hey Ronny,

I have my concerns about FCPX 10.3 performance as well.
I just started with the edit of a long documentary in FCPX 10.3 (no multicam but lots of footage). Coming from a FCP7 background I was surprised to see how slow the FCPX browser is. I turned of filmstrip and audio waveforms in the browser and timeline. Still copying clips (sync clips) from one event to another or from one library to another takes a long time (spinning beach ball ...). This never happened to me in FCP7, actually in FCP7 I can cut and copy footage in the browser from one project or from one folder to another instantly.
I do realise that in FCPX there is more metadata to be copied, but still I found this proces really slow. My footage is stored on a external HHD outside of my libraries (the libraries are stored on the same hdd). I work with PRORES LT HD. I know I don't have the fastest laptop (I do have 16GB RAM), but the same project in FCP7 runs very smooth.
Same for timeline performance: in FCP7 I have absolutely no lags, in FCPX I sometimes need to wait a couple of seconds before it starts playing (without filmstrip and audio waveforms). The playback quality is on better performance.
This performance makes me doubt to continue with FCPX.

Is there a way I can get better performance in the FCPX browser and timeline?

Thanks!

MsJustine wrote: It is a fact for me, Sierra+10.2.3/10.3 does not work, that it is not a fact for you is irrelevant, it does not work for me, that is a problem both for me and for Apple.

What you say? We all waited almost a full year and we got 10.3 and all her bugs, yay for waiting!!!

Why not try El Cap, simply I do not trust it, Yosemite and 10.2.3 works, the more recent the OS, the more unstable it seems to become. I would prefer to go even further back, but 10.2 might not work, sort of stuck at this point.

Apple if you say are ironing out the bugs, took forever to update 10.2.3, just a small patch to fix the lines and misplaced names of hours min frames etc, which has not been patched, just forgotten, so I guess waiting for something to not happen?

Why has Apple not patched the lines in the timecode window???

Yes indeed. I think you should request a full refund for your purchase price for FCP X 10.3 update. After all, if it does not work for you and you certainly deserve to have the fee retuned to you ... oh wait ... wasn't 10.3 free? ... as was EVERY update to FCP X for the PAST FIVE YEARS!

I believe in holding developers to task ... however ... I once again point out that your personal experience with 10.3 is NOT universal in scope. As is you wariness of El Capitan. Many users (seems to be the vast majority) are experiencing few if any detrimental difficulties with 10.3 on El Capitan or Sierra.

Yes, the problems shared here do require Apple's attention and due diligence ... but ... in light of the circumstances it seems entirely unfair and grossly inaccurate to label 10.3 as a total failure.

Yes it is not a total failure, but 4 versions in under 5 years? 10.0, 10.1, 10.2, 10.3..
Something is wrong, fcp7 was not very different from 6 and 5 and so on...

Yet in just a shade over 60 months, we have had 3 totally different versions of the same thing...

10.0 was a total failure, 10.1 to 10.2 was a total failure, as no updates to patch, just release a version that looks vaguely similar but is causing issues....

um...

MsJustine wrote: Yes it is not a total failure, but 4 versions in under 5 years? 10.0, 10.1, 10.2, 10.3..
Something is wrong, fcp7 was not very different from 6 and 5 and so on...

Yet in just a shade over 60 months, we have had 3 totally different versions of the same thing...

10.0 was a total failure, 10.1 to 10.2 was a total failure, as no updates to patch, just release a version that looks vaguely similar but is causing issues....

um...

If FCP X has been the 'total failure' for you ... why do you still use it? With all these 'failures' you document ... did you only begin to use FCP X at 10.2.3? Why did you buy a 'failed' app in the first place?

While I have empathy for your situation, I have no sympathy for your point of view. Yes, as I have said several times, Apple has a duty to squash bugs that have come to light ... but ... they don't deserve the blame for the level of failure your are trying to portray as 'fact' ... it simply isn't true.

I've edited a long feature film in 10.2.3 and I experienced more lagginess than in 10.3. Just for testing, I opened that project with this last release and I find it quite snappier when I move clips or simply using the precision editor.

Yet I must admit that when I edited in the past long form productions like weddings (60min long or more) with more effects loaded on the clips and more composition work, FCP7 was way much more responsive and fast. Sometimes it appears to me as if FCPX had to process more lines of code in order to make some decisions.

There is one function that I find quite worse in FCPX, even on 10.3, than in any other NLE and that is MATCH FRAME (or Reveal in Browser in FCPX): it's SOOOOOO SLOW loading clips in long form productions that I find my self using this feature less and less...

Ronny wrote: we are trying to figure out why this particular type of project is laggy

What type of project would that be? You don't mention what "type" they are.

Ronny wrote: No-one can deny that these projects, which actually are all of the same type

What type is that? Again, you seem to be blaming the editor. FCPX should be able to handle any "type" of project effortlessly. Thankfully this thread has finally brought light to the issue. Maybe it will no longer be ignored.

Ronny wrote: I think we should be very careful about launching bold general statements based on a very particular issue.

Why's that? I know people don't like it when their preferred NLE gets criticized, but we need to call it for what it is. I don't believe I've said anything that's not factual. Like you I'd also like to find out what's causing this.

Ronny wrote: it is related to a very specific type of work.

What very specific type of work is that? Again, you don't say or give any clues.

Ronny, how about you upload an XML file of a long-form edit with more clips that gives you zero issues so we can test it out on our systems to see if "your type" of projects work well on our systems. That would be extremely fair of you.

The type of project that was shared to Dropbox.

"FCPX should be able to handle any "type" of project effortlessly."

Why would you make that assumption? If you are pushing the limits of the application and the media in it beyond the capabilities of your hardware or of the operating system, why wouldn't it perform poorly?

Because bold, sweeping generalizations are usually stupid.

But what's special about the "type" of project that was uploaded as an XML? Nobody ever said. I will say this for the 3rd time, Tom. Maybe this time you will read it: It's not a hardware issue. CPUs don't get anywhere near maxed out, RAM never goes above 4GB used for the application when trying to drag stuff around. Also, no media is even connected so it's not a media issue. We're literally just trying to drag clips with no content around a timeline. I get drag lag with smaller projects than this. Sorry, I know you want to be a cheerleader for FCPX, but recognizing that there is a problem is the first step towards solving the problem.

And I'd appreciate it if you didn't call me stupid. Personal insults have no place on this forum.

I absolutely agree with you, Redifer. I've been editing on FCPX since 2011 and I love it, but acriticism doesn't help us at all.

Redifer wrote: But what's special about the "type" of project that was uploaded as an XML? Nobody ever said. I will say this for the 3rd time, Tom. Maybe this time you will read it: It's not a hardware issue. CPUs don't get anywhere near maxed out, RAM never goes above 4GB used for the application when trying to drag stuff around. Also, no media is even connected so it's not a media issue. We're literally just trying to drag clips with no content around a timeline. I get drag lag with smaller projects than this. Sorry, I know you want to be a cheerleader for FCPX, but recognizing that there is a problem is the first step towards solving the problem.

And I'd appreciate it if you didn't call me stupid. Personal insults have no place on this forum.

If you have drag lag in a project (imported xml) without any connected clip than it looks like there is really something wrong with FCPX. Hopefully this will get sorted out soon.
How is the GUI performance in your FCPX browser with this project?