-
Background processes are an impediment to starting the edit
-
One thing that causes a lot of background work is dumping large size photos into X. For example a dng file out of my Nikon runs 20 MB per photo. I usually run them through Lightroom and export them at about 1 MB jpg before importing them into x. I have never tested how small (MB?) they can be made for a 1080 p file before there is visible degradation in the resulting x video. Anybody have a rule of thumb?
-
At the risk of having everyone accuse me of shouting “you’re holding it wrong” – a part of the issue might be that you guys are STILL seemingly trying to use X like an old style system.
Know what you can do INSTANTLY – literally right after everything shows up in your Browser? You can start to move your edit forward via all the many database preparation tools X pioneered that do not need ANYTHING to be prepped to function. Including audio travel management, roles assignments, and Reject/Favorite tagging.
Every traditional editor I’ve ever walked through X has this same bias. They don’t think their edit has commenced until they have clips on a timeline. It’s maddening since I’ve been talking about this for six years now.
Removing ALL the crap from your view via Reject saves sometimes whole days later on. It clarifies editorial thinking EXACTLY like a string out – except it’s 100 times more flexible.
After Hide REJECT – the shape of your raw materials starts to emerge – telling you precisely where you have options and where you might have content holes.
And it works with the instantly accessible finder text feedback, so nothing needs to “process” before you get working.
Remember – all this with Background Rendering off and nothing to process except waveforms and transcodes if you need them – And THOSE can be stopped at will and re-started to run overnight!
And this stuff also doesn’t slow down the most powerful prep of all – keywording – something I’m doing throughout the entire prep process as I go.
After six years on X, I’ve truly come to see Tagging AS editing. It’s a “first cut” in everything but name. Those not comfortable with X thinking just miss this because it happens away from the “timeline” but it’s as palpable to me as using a motor to fix an AC rather than starting with magnets and wire and assembling the motor from scratch. Precision range keywording creates useful custom “parts” I can use to build more efficiently with later.
If clients are antsy to see something immediately, I can do exemplars as I identify them – and let them automatically background process during short breaks.
The point is that there is lots and lots of effective edit prep that can take place during the first few days of a typical X pre-edit period that lets me move my edit very much forward – they just don’t take place on my timeline.
And in my experience, after a few days on this stuff – Making and syncing Multiclips multi-cams prepped, batch re-naming internal assets for organization, prepping reference clips like Sync and Compounds – 100% of the time all that background stuff like waveforms, transcodes, and ALL those background processes are typically done and I’m ready to CUT .
With that prep properly accomplished, the edit itself is usually pure joy, since everything is sorted, rated, searchable and I feel like any change or request a client lobs at me will just make me grin.
Once again, if you try to drive X using non-magnetic prep thinking and expectations (the “the edit happens only on a timeline) approach) X will probably slow down to about the efficiency of any other NLE.
It’s only when you embrace its complete gestalt – that things start to really fly.
My 2 cents.
Creator of XinTwo – https://www.xintwo.com
The shortest path to FCP X mastery. -
Different horses for different courses andy. The CC was the right tool for the job due to the amount of motion graphics that we could quickly relink from Ae.
The project libraries were getting above 4Tb in size with 8 and 6K red footage and some proxy prores files, and each time we imported a new file or just opened the project it slowed to a crawl and took nearly an hour to become functional. Adobe tech support told us to cut the libraries down and just work from proxies, but relinking to the original files became nearly impossible. Admittedly, if we just worked from the prores files, premiere was fine and the new bin locking function is really interesting as it will allow us to work as a team on larger projects.
We edit on nearly all programs – avid, premiere, fcpx and resolve – whichever is the best tool for the job and more often than not with an honest evaluation we are using fcpx and resolve more often.
Co-owner at Pollen Studio
http://www.pollenstudio.co.uk -
[Claude Lyneis] “Anybody have a rule of thumb?”
It’s all about the raster, Claude.
Video is still fixed at 72dpi. So if your master is gonna be HD at 1920×1080 – and you want to be able to do a 2x push – importing it as larger than 3840×2160 at 72dpi is wasted.
If you’re doing a 2K or 4K project – the math works the same – but that basic 72dpi raster standard means a 24 megapixel raw DSLR raster is still almost always SERIOUS overkill.
If you want to do a Ken Burns thing and do a 10x zoom to pick a single face out of a graduating class photo – it’s OK to do a few big rasters by scanning at 300 or 600 dpi and let that pixel density scale. But as you’ve discovered – doing 50 photos like that will likely choke X because it’s default is not to “dumb down” any raster, but to try to preserve and manipulate every dot you feed it.
How I’ve come to see it. Good luck.
Creator of XinTwo – https://www.xintwo.com
The shortest path to FCP X mastery. -
[Bill Davis] “Once again, if you try to drive X using non-magnetic prep thinking and expectations (the “the edit happens only on a timeline) approach) X will probably slow down to about the efficiency of any other NLE.
It’s only when you embrace its complete gestalt – that things start to really fly.
“Not true at all Bill
[Bill Davis] “Every traditional editor I’ve ever walked through X has this same bias. They don’t think their edit has commenced until they have clips on a timeline. It’s maddening since I’ve been talking about this for six years now.
“It might be maddening for you Bill, it’s a great system that works for you and a lot of people I’m sure, but a LOT of Editors simply don’t work that way and FCPX has many speed advantages even if you don’t use your “database” style of editing.
[Bill Davis] “Once again, if you try to drive X using non-magnetic prep thinking and expectations (the “the edit happens only on a timeline) approach) X will probably slow down to about the efficiency of any other NLE.”
So if you don’t use YOUR method it makes FCPX no better than other NLEs?? Rubbish – I hardly use tagging in FCPX and I find it much faster than other NLE’s In fact I would argue that the speed of the skimmer and it’s ability to get through rushes really quickly can actually negate the need for tagging at all in some edits.
And before Andy chips in, you can do many of the same organisational tasks in Premiere Pro while it’s audio conforming as well 🙂
-
[Bill Davis] “Know what you can do INSTANTLY – literally right after everything shows up in your Browser? You can start to move your edit forward via all the many database preparation tools X pioneered that do not need ANYTHING to be prepped to function. Including audio travel management, roles assignments, and Reject/Favorite tagging.”
Sorry Bill, but the problem is in the browser. You usually can’t effectively review a clip until the processing is done. For example, in list view, I try to toggle down through the clips and in the upper filmstrip viewer often nothing is visible until it’s ready. At best it’s stuttery. So no, doing something “instantly” just isn’t the case with many types of media.
– Oliver
Oliver Peters – oliverpeters.com
-
[Oliver Peters] “You usually can’t effectively review a clip until the processing is done. For example, in list view, I try to toggle down through the clips and in the upper filmstrip viewer often nothing is visible until it’s ready. At best it’s stuttery. “
I’m not seeing this at all on my system.
If I’m in filmstrip mode I can toggle through the clips and see video just fine. No stutter.
I have the waveforms turned off in the browser but if I turn them on I can tell it’s taking a while to load them in the browser.
The upside is they load immediately in the timeline, which is funny. I’m not sure why they are ready in the timeline instantly but not in the browser.
The timeline is what counts if I’m in a hurry so it hasn’t slowed my work.
-
[Bill Davis] “At the risk of having everyone accuse me of shouting “you’re holding it wrong” – a part of the issue might be that you guys are STILL seemingly trying to use X like an old style system.”
Honestly, Bill. I don’t appreciate the condescension.
The first step to recovery is admitting there’s a problem.
4 heavy FCPX users have said that FCPX is slow upon import. Sometimes I need to start editing right away, doing boring stuff like making window burns, or teasers.
I do organize first, and it sure as hell doesn’t take two whole days to organize, that’s the beauty of FCPX, it goes fast.
I now leave the machine on overnight after I import. It’s the only way to come back to a normal performing NLE. Once that process is done, FCPX performs great, yet there are more beachballs in 10.3.4. Something changed and this has happened before with point releases. Some go faster, some slow down.
It’s OK.
-
[Tony West] “The upside is they load immediately in the timeline, which is funny. I’m not sure why they are ready in the timeline instantly but not in the browser.
The timeline is what counts if I’m in a hurry so it hasn’t slowed my work”I think you and Bill are going to need to take that one out into the back alley ☺
– Oliver
Oliver Peters – oliverpeters.com
-
Cancelling out of background process helps. Of course, then in the list view, the first time you hit a clip it takes a second of so to populate the top filmstrip viewer with images. Still better than when the background process are going. Also that’s with waveforms off in the browser. Definitely slower with them on.
– Oliver
Oliver Peters – oliverpeters.com
Reply to this Discussion! Login or Sign Up