10.3 issues

First, I didn't call you stupid. I made a comment about sweeping generalization.

My sincere apologies if you felt insulted because I respect your opinions.

Did you see the project that was uploaded? I've never seen one this complex or anything like it. I've worked with a number of editors doing long form projects, none of whom produce work anything like this.

You don't think the problem is in the graphical display not keeping up with what you're doing? That's not a problem with either CPU or RAM. Dragging clips in the timeline doesn't actually move any media anywhere. The specifications of the media matter but not the media itself. It's not like files are being rearranged on your hard drives, so content or no content doesn't matter if it's an interface problem.

This is the last thing I will say on this matter:

I have clearly described the type of project after having downloaded and tested it, you just need to read what I said.

I certainly have not blamed the editor in any way. If you can find one sentence in which I say that the editor is to blame, you are free to quote it here. On the contrary, I have had a private conversation with the editor and he absolutely knows what he is doing.

This entire afternoon (our time) I have been in contact with people who work on long-form, both for television and movies. And if you would doubt my word on this, I'm sure these people will be happy to come here and confirm this. We have been doing live tests on long and complex timelines over Skype, comparing the structure of our timelines to find out when this drag-lag happens and when not. And we have come to a very clear conclusion which I will forward to Apple next week, together with XMLs and with videos we have made of our tests. These confirm that there is an UI issue with a very specific combination of assets on a timeline, but that this issue is not related to long-form work in general as has been pretended a few times here.

I agree that a-criticism does not help anyone, but nor does posting generalizations that are not founded on actual testing and facts. I prefer talking with people offline to find out exactly where a problem can find its roots, and then report this duly documented to the makers of the program through the appropriate channels. I have done this silently for many years now, and I have found this way of working to be much more effective than ranting on public forums. As Tom said: bold, sweeping generalizations are usually stupid.

- Ronny

Ronny you ROCK!!!

We are fortunate to have Ronny "The Voice of Reason" on this forum. Thank you Ronny!

OH MY GAWD. The circle-jerking on this forum is amazing. Ronny, if the editor had not edited in that "type" he wouldn't have the issue, according to you. It is his fault for doing that "type" of editing. How should he have edited it to avoid the issue? Please post an XML with more clips so we can see what type works well. Put your money where your mouth is. Other people whom I do not know confirming does nothing at all to help discover what the issue might be, nor prove that it's just this "type" of timeline. The uploaded timeline really didn't seem overly complex. Also Ronny I am not seeing where you said what type of projects these are, other that they are from Denmark. You have said that you have longer projects with more clips that work fine. I'd like to see that. Please?

I don't think anything I said was unreasonable at all. If you think it was, please point out the unreasonable things I have said. Thanks.

I think there is a very valid point when saying there is some kind of slowness or low level of responsiveness when loading media in big libraries with tons of clips. Metadata-driven organization is amazing and don't know for sure if this is the cause of that problem, but loading clips -for example when "Revealing in Browser"- should be quick. How much time did FCP7 take to load a clip when matchframing it, no matter the size of the project or number of clips involved? What do you think?

ronny courtens wrote: Hey Mikael... 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?

...Yup

Mikael gave me that xml to post here, but he joined the thread himself as well.

This thread has unfortunately become quite bash-y.
I'll do my part to keep on point.

For all practical purposes, an XML like Mikael's has been quite typical for a lot of "broadcast creative" productions I've been involved in over the last 10-ish years. Both as colorist (having been handed quite a lot of timelines from many editors over the years) and as an editor myself.
Both Mikael and me are power users. I personally spend 8+ hours every day in FCPX and believe I have a very good grasp on the post production side of things and am a very good trouble-shooter to the point of me starting this whole drag-lag issue here on fcp.co as a last, desperate resort.
It took some posts, but I'm glad we now have this issue confirmed, although isolated to some specifics not yet uncovered.

Disregarding some "new" ways of working, there is nothing inherently different about the way I do creative editing in X than FCP7 or Premiere.

For comparisons sake, I just imported the very same 40min XML that was shared first, into Resolve.

Here's the video of me navigating around the timeline, scrolling, zooming and dragging clips.



The major difference would of course be the lack of effects and transitions of which the majority does not carry over.
But I also used the new remove attributes in 10.3, and even after doing that, I still had the lag.

While the issue in 10.3 will hopefully be addressed, I would personally love to know what the cause of it is, seeing as there is such a big difference navigating the same offlined timeline in two different apps.

Hey Chris,

Thank you for confirming that the xmls are from the same production. I agree this thread has become quite bashy, so I won't add anything to it anymore. I am in contact with Mikael, I will be back in touch with both of you on Monday so we can work on a solution.

Ronny

ronny courtens wrote: This is the last thing I will say on this matter:

I have clearly described the type of project after having downloaded and tested it, you just need to read what I said.

I certainly have not blamed the editor in any way. If you can find one sentence in which I say that the editor is to blame, you are free to quote it here. On the contrary, I have had a private conversation with the editor and he absolutely knows what he is doing.

This entire afternoon (our time) I have been in contact with people who work on long-form, both for television and movies. And if you would doubt my word on this, I'm sure these people will be happy to come here and confirm this. We have been doing live tests on long and complex timelines over Skype, comparing the structure of our timelines to find out when this drag-lag happens and when not. And we have come to a very clear conclusion which I will forward to Apple next week, together with XMLs and with videos we have made of our tests. These confirm that there is an UI issue with a very specific combination of assets on a timeline, but that this issue is not related to long-form work in general as has been pretended a few times here.

I agree that a-criticism does not help anyone, but nor does posting generalizations that are not founded on actual testing and facts. I prefer talking with people offline to find out exactly where a problem can find its roots, and then report this duly documented to the makers of the program through the appropriate channels. I have done this silently for many years now, and I have found this way of working to be much more effective than ranting on public forums. As Tom said: bold, sweeping generalizations are usually stupid.

- Ronny

Ronny is not blaming the editor and I would know because I AM THE EDITOR.

Ronny's mission is to solve these issues within FCPX and that is all that matters.

Be nice to each other everybody.

Mikael

chrisb wrote: While the issue in 10.3 will hopefully be addressed, I would personally love to know what the cause of it is, seeing as there is such a big difference navigating the same offlined timeline in two different apps.

It is my personal feeling that it is some sort of memory mismanagement within FCPX. I am not a programmer so I can't guarantee that, but that's what I feel it is. FCPX doesn't seem to be accessing the memory fast enough. Or maybe it has something to do with the auto save function. Does Resolve auto-save after each time you touch anything? But then that shouldn't interfere with timeline scrolling and resizing. I am really curious why FCPX uses so little RAM.

Someone please chime in if I'm mis-remembering how I used to cut in FCPX because it's been a few months for me. But I remember I used to be able to hit delete (the delete-backwards key on an extended keyboard) on a selected range in my primary storyline and it would do a ripple delete. Now it seems to just reject that range on the clip in the timeline. If I blade at the in-point then delete-backwards will do a ripple delete of the segment I want to cut. The delete-forwards key is working the way it used to when just a range is selected (doing a non-ripple delete of the selected range).

Am I incorrect in how I remember working before 10.3? Or is this possibly a setting I need to reset or bug?

Delete key next to = should be ripple delete.

Is this audio? There's been a behavior change. Selected segment is silenced. Maybe be intentional, but it has a buggish quality to it.

That's it, Tom. I'm editing for a podcast and this is audio on the primary storyline. I don't think it did this prior to 10.3. Wish I could at least hold down option or something for a ripple delete rather than silencing.

Thanks for the quick response.

Command+option +delete will ripple delete audio for you

Do you think the change in behavior is by design?

No idea Tom, according to Richard Taylor from FCPRadio it's confirmed as a bug by apple. The intension is to have the delete key work as mute(disable) when you select a range in the component(subrole) level, but when you work on the clip lever it's supposed to ripple delete

Another disturbing example of DRAG LAG in FCPX.

It is simply impossible to work in a timeline as unresponsive as this.

vimeo.com/194057113

More items in a timeline is the same as more unresponsive behavior.

Unbelievable..

Kyster wrote: Another disturbing example of DRAG LAG in FCPX.

It is simply impossible to work in a timeline as unresponsive as this.

vimeo.com/192894133

More items in a timeline is the same as more unresponsive behavior.

Unbelievable..

10.3.1 has done little, if anything, to address this. I did feel like there was a wee bit less lag on the XML posted here, but it's still nigh on impossible to work with efficiently, and nowhere near Resolve-responsiveness (and having Resolve as a baseline for NLE responsiveness is somewhat telling, I think).

I have also communicated with someone from Metronome Productions, and they are experiencing severe drag-lag across machines.

As I said in my last e-mail, I have also been in contact with my friends at Metronome. And I have asked several other people who work on similar projects to provide feedback about this. A full report has already been sent to people at Apple 3 days ago, and I will add another one as soon as I get more details from the people I have contacted. I will keep you updated on how things go.

- Ronny

ronny courtens wrote: As I said in my last e-mail, I have also been in contact with my friends at Metronome. And I have asked several other people who work on similar projects to provide feedback about this. A full report has already been sent to people at Apple 3 days ago, and I will add another one as soon as I get more details from the people I have contacted. I will keep you updated on how things go.

- Ronny

I have not been included in those emails, so didn't know