Notes From a Feature Doc Edit With Productions in Premiere Pro
UPDATE — 11/05/2024 — For anyone who wants to dig even deeper, I recommend this recent guide on all aspects of Productions. It is extremely thorough and will be a good supplement to the article below. (the only aspect I disagree with is the recommendation to split feature edits into reels to limit individual project file size. This is unnecessary in my experience.)
UPDATE — 05/10/2023 — This article was originally written in the spring of 2021. Since then I’ve had more experience with Premiere’s “Productions” workflow. All the benefits and caveats I wrote about in 2021 remain true. However I have updated the article with more detail and an added caution based on the more recent experience.
In 2020 I edited a feature doc, Amy Tan: Unintended Memoir, with Premiere Pro’s new (at the time) “Productions” workflow. Short story: this is a huge new advancement for Premiere that dramatically improves the software’s stability for large projects. It is well worth the caveats I outline below.
This was the fourth feature doc that I cut on premiere. For me the two consistent problems on long form projects in Premiere have been the cumbersome project file size and difficulty sharing sequences between editors without accumulating piles of duplicate clips. Since I’m usually working alone, the file size issue has been the biggest downer for me. Over the course of a feature edit I build up dozens of versions of the film, on top of dozens more assemblies, selects sequences, sync sequences, etc. This means lots of very long sequences that significantly increase the size of the project file. By the end of an edit, opening and saving a project becomes frustratingly slow and crashes are frequent.
In stepped Productions offering major improvements for large projects. When I was considering switching into a Productions set-up for the Amy Tan film I found a lot of helpful write-ups on best practices, but no real-world case studies. No descriptions of bugs or quirks or real world limitations that I could expect over the course of a long project. I was excited enough to try it anyway and decided to take some notes along the way so that my experience could become a useful case study for other editors. I’ll start with the good stuff, but I’m mostly writing to share the caveats which I have not seen written about elsewhere.
The Basics
If you don’t know what Productions is check out some of the other write-ups and videos on the basics. There are a lot and you will need to understand the established best-practices before you get started. This document from Adobe is a really helpful guide. Keep it handy. This blog post is also really thorough.
To put it simply, Productions allows you to break up a standard project into lots of smaller projects that are all accessible at any time within the same “Production.” In Premiere the Production panel is like the first level of the old Project panel and the individual projects act as your first layer of bins. On the finder level a Production folder containing multiple project files replaces the old stand-alone project file.
By spreading the whole film across multiple project files within a Production, Premiere keeps individual project files very small and allows you to leave projects closed when not in use. This dramatically reduces the load on the system and makes the whole Production much more stable than a single huge project file.
My Set Up
For the Amy Tan film I worked entirely from my home studio off a single external RAID(full specs on system bellow). I had an assistant who worked from her home on a mirrored drive. We did not use a remote server, or any cloud syncing tools other than the basics(Dropbox, etc) for exchanging files. We were not using the collaboration features of Productions.
I started the film in a normal project file before I knew about Productions. Once I decided to commit to the Productions workflow I added my existing project file into a new Production then broke it out into lots of individual projects, treating each project like the first level of bins. This process was very easy.
I organized the source into different projects based on footage type(production footage, archival, music, etc), and further separated the production footage into smaller projects based on category(three different projects for Amy Tan production footage, one for supporting characters, one for book inserts). Then I had separate projects for all sequence types including a project for the selects sequences for each character, an edit project, assembly projects, etc.
By the end of the edit I had around 100 projects in the Production, most of which were left closed most of the time. If you popped in to my office at any given time you would likely see my current edit project, my archival assembly project, and one or two other selects or source projects open. The rest would be closed, but immediately accessible. I kept one active edit project at a time. Every time I posted for a big review with the team I would create a new edit project for the next version. Between the big reviews I would make as many versions as I needed within the same project.
Payoff
No individual project file got bigger than 15mb and most were considerably smaller(like 1 or 2 mb). Meanwhile the entire Production folder was over 400mb. For comparison the last film I cut ended with a project file size that was about 80mb. That film was only 60 min and used about half the source required for the Amy Tan film. On previous terrain it would have been considered a nimble project. (I think the project before that grew to around 200mb). Why does this matter? When I recently had to open that 80mb project file I timed it. The project took over three minutes to fully load compared to about 30 seconds for my Amy Tan Production(with 3 projects open) — (in both cases using my outdated 2015 iMac). With larger project files the autosave becomes enormously intrusive. Every 15 min my flow is broken for a 10 or 20 or 30 second progress bar(especially annoying when your director is at your side). In Productions, the only time I even thought about the autosave was when I had more than four or so projects open at a time. Premiere still saves each project individually within the Production so the more projects open the more Premiere has to save(and the more the burden on the system). Whenever I got caught with one of these slightly longer auto-saves, it served as a good reminder to tidy up by closing projects that I was not using.
It is also notable that I had hardly any crashes throughout the life of the project. Crashes became a bit more frequent towards the end of the film, but nothing like I was used to on past projects. When I did have to dip back into my prior film I was reminded not only of the slow open time, but also of the overall sluggishness. When an edit spans months (or longer) there is a gradual stretching of the confines of a single project file. There are no similar limits within a Production that I can tell. The Amy Tan film did not feel any more sluggish at the end than the beginning.
Collaboration Benefits
As I said, my assistant, Ilana Rappaport, and I were working remotely without a cloud server so we were not using the collaboration benefits that are the marquee features of Productions from Adobe’s perspective. That said, there was still a big improvement in how we were able to share sequences. In the past sharing sequences between editors always resulted in the appearance of duplicate clips within the project. Adobe improved this over the years, but in my experience, the issue never went away. Finally, it seems, Productions has cracked the code on sharing between editors. We found it extremely easy to share sequences without any duplicate media or friction around re-linking.
After the Amy Tan film I finished another feature with Productions using Lucid Link as a cloud server to host the Production folder while still keeping all the media on a local raid. The assistant editor had a mirrored raid and we both worked off the same Production folder on the Lucid server. We only really overlapped during the early stages of the project, but I left the production on Lucid throughout the edit. This process was seamless and definitely seems like the way to go for shared edits. I’ve heard of others successfully using Dropbox instead of Lucid Link in the same way. I can’t vouch for that workflow myself, but I would definitely consider it if a future production doesn’t want to shell out for Lucid.
Tips
Break up your projects into either “Source” projects or “Edit” projects — in other words keep your timelines and media in separate projects.
Do NOT duplicate Source projects within a Production — many editors will duplicate projects — sometimes daily — to keep backups of their work in case of crashes or mistakes. If you are one of these editors, DO NOT duplicate the Source projects within the Production as this will result in duplicate copies of the source clips. That means different timelines will eventually reference different copies of the same clip. (This is one of the reasons to follow the tip above). If you want to keep duplicates of your work as a backup, I suggest duplicating or zipping the whole production folder and adding a date and time to the duplicate. Then move the duplicate into a “Back-ups” folder and continue working in the original Production. You can also freely duplicate the Edit projects and timelines as much as you want.
Avoid re-organizing Source media mid-edit — the farther you get in an edit, the more timelines and the more projects you will have. Each of those timelines and projects will add more inter-dependencies between the edit projects and the source media. If you move the source media those inter-dependencies can get broken. Premiere will sometimes be able to keep track of these moves, but not always.
If you are migrating a project into Productions after extensive editing you might consider leaving all or most of your source media in a single project, while still breaking up timelines freely into separate projects.
If you do need to move source media from one project to another, open all edit projects — or at least those edit project that might contain references to the source media in question — before you move the source medie. This ensures that all projects “see” the move and should avoid broken references.
If you sort media mid-edit, use “Re-associate Source Clips…” —[UPDATE — 12/13/24 — I’ve written an new guide on clip re-association here.] When you right-click a clip in a sequence and select “reveal in project”, the Source project for that clip should open and reveal the clip. However, I periodically ran into an error “The source media has been deleted or moved from its project. Do you want to search in other open projects?” In these cases I had to find the right Source project and open it before doing a “reveal in project”. I suspect that this only happened for clips that had been moved between projects after the production was initially set up. If you run into this issue you can try to “Re-associate Source Clips…” under the Edit menu. This feature is not very robust and does not always work, but, in theory, it can be used to restore links between a timeline and Source clips when those links get broken. (NOTE: It works best if the project you want to “Re-associate” to is already open.) (Feature request)
Don’t use XMP for markers… EVER — Premiere has three evil little check-boxes under Media Preferences related to XMP. These should be left unchecked at all times — especially “Write clip markers to XMP”. If this box is checked clip marker metadata will be saved to the video file itself NOT the project file. In my experience this is like adding little metadata time-bombs that will explode on you at some future date. Even if there are peculiar situations when it might, momentarily, seem nifty to add the markers metadata directly to media files, there is no situation when this is essential. Instead, saving markers to XMP will only add confusion when you are sharing a project or sharing different copies of media — some with XMP markers and some without — especially in the context of Productions.
Set a short cut for “Project View Preset” — As far as I know, there is no way to set a default metadata display(ie custom columns) or column order in the Project panel for all projects. Instead you have to change the metadata display each time you open a new project. That’s not a big deal if you only have one project, but within a Production I found it a little tedious to change to my custom columns for each new project. It turns out you can save a “View Preset” under the project panel dropdown menu AND add a keyboard shortcut for your custom preset. This is very handy within Productions. Each time I opened a new project, I could change columns settings to my preset with a single keystroke.
Close projects that you are not using — Just like opening lots of new tabs within a single project, opening lots of projects can get messy and confusing. Within a Production you are also adding to the load on the system with each additional open project. This will become obvious when your auto-save kicks in and you have to wait for ten individual progress bars for your ten open projects.
Don’t Touch the Production Folder — On the finder level, once you are up and running, your film will exist across many individual project files and folders within a single Production folder. It is important not to touch any of the files in that Production folder or try to move the Production folder once the project is underway. If you do need to move the Production for any reason, keep in mind that the projects may, initially, reference each other at their original file path. So if you move a copy of your Production folder to a new location it is a good idea to move, delete or rename the original Production folder. If not, whenever you open a timeline and try to “reveal clip in project”, Premiere might open the source project in the original Production folder. If the original Production has been renamed, Premiere will see that the original file path is broken and look for projects within the new Production folder instead.
Handing off a standalone project — If you are not using shared storage and want to share a single sequence with another editor as a standalone project you can simply move a copy of the sequence into a new project, then select “Generate Source Clips for Media” from the edit menu and Premiere will add all the source clips referenced in that sequence into that project. You can then reveal the project in Finder and share it as a standalone project. If the other editor already has the Source media loaded in their Production, then you can skip the “Generate Source Clips…” step and simply hand-off the project with only the timeline. Once imported, the clips in the timeline will link up with their respective Source clips on the receiving end.
Caveats
Yes, there are many caveats to working within Productions. After all, it is the biggest redesign of project workflow in the 10 + years I’ve been using Premiere, if not longer. Naturally, features that are designed to work within a single project are not going to work the same when your film is spread across 100 projects. Here are the biggest limitations I encountered:
Premiere’s View of Media is still Limited to Individual Projects — this is the biggest limitation imo. Anything that would require Premiere to look at metadata across the entire production, rather than a single project, is now out the window. This includes:
- NO SEARCH FUNCTION — you can still search within an individual project, but your media is now spread across several projects and there is no way to search across the whole production. So if you are someone who likes to add lots of tags in your clip metadata and then quickly search based on those tags you will need to find a new workflow. (Feature request)
- CLIP USAGE LIMITED TO INDIVIDUAL PROJECTS — When I work I always keep the preview window open in the project panel and am frequently using the Clip Usage drop down. Clip Usage only works within a project, but now that my sequences and clips are all in different projects there will never be any info in the clip usage drop down. (Feature request, Feature request)
- NO REVERSE MATCH FRAME — Along the same lines, if I am looking at a clip in the source monitor that I know is used in an open sequence, I cannot reverse match-frame to see where that clip is located in the sequence unless the clip and timeline are in the same project. (Feature request)
Nests do not move well between projects — there seems to be a hard link between a nested sequence and the sequence it lives in requiring them to always be in the same project. When I nest a couple clips in a timeline the new nest shows up next to that timeline. If I try to move that nest into a different project, ie a “nests” project, the nest is duplicated and the nest in my timeline still references the original nest in the Edit project. If I want to duplicate and move that timeline into a new project, a new copy of the nest will automatically show up in the new project as well. This could get messy if you use nests a lot. Fortunately I don’t. Importantly, this has not been an issue for multi-cam clips, which are basically fancy nested sequences. Premiere still sees them as clips not nests.
Crash Recovery is not adapted to Productions — When there is a crash with a single project, premiere is generally really good at preserving unsaved work. When you reopen, Premiere asks if you want to re-open the prior session and then asks you to save a new version of the project. This wonderful feature has not been adapted to Productions. When I did experience a crash, premiere gave me the usual prompts about attempting to save my progress, opening a prior session and then saving a copy of the project, but this only applied to one of the open projects and not necessarily the one most in need of saving. AND, once reopened the new recovery copy of the project gives me a “Duplicate ID” error — meaning the Production sees two copies of the same project. You can remove the older version of the project from the Production to get rid of the duplicate ID issue. The bigger problem is that the crash recovery is not able to save progress on all open projects. You can still recover manually using the auto-save vault, but the auto-save still functions per-project. In other words, there is no way to simply restore the whole Production to where you left off. Instead you have to identify which projects might have unsaved work, and find those projects in the auto-save vault, which is now a lot messier since you are auto-saving dozens of projects instead of a single project. (It’s notable that this has not been a major problem for me since I have had very few crashes while working with Productions.)
- SIDE-EFFECT FROM CRASH — Also when you reopen after a crash the projects that were open during the crash show the locked icon(as if someone were working on them in a shared storage situation). If I open those projects, the locked icon goes away. However, after one crash I did not realize my music project had been open and was left “locked” when I re-opened. This led to peak files for all my music being recreated next to the music project in the Production folder rather than in my cache. After a half day of troubleshooting I discovered this was causing every Save to take several minutes. After finally finding these extra peak files, I deleted them from the Production and from the Trash folder within the Production folder in the finder. Once they were gone, my saves went back to normal. SO the rule is: after a crash, check all projects, and open any that have the project lock icon.
Clip Markers are now… confusing — I’m not sure if this counts as a caveat or a bug, or just a word of caution, but if you like to use clip markers, take a moment to consider how they work in the context of Productions. Your Source clips are now in one project and your edits in another. If your Source project is closed and you add a clip marker to a clip instance in an open timeline, what happens to the Source clip in the Source project? Nothing… until both the Source project and the Edit project with the new clip marker are open at the same time, at which point they should update to the latest marker state. The new marker added directly to the clip in the timeline will show up on the Source clip in the Source project.
BUT what if you change an existing marker in the timeline, then close that Edit project before opening the Source project? What if you then open the Source project and make a different change to that same marker? At what point do these changes collide and which change ultimately gets adopted? I believe Premiere is supposed to adopt the most recent change for all instances whenever multiple instances are open at the same time, but I don’t fully understand how this works in action and can imagine it leading to some confusion. If you are big on clip markers, take some time to experiment with different scenarios or stick to strict rules like only adding clip markers while you log clips in the Source projects, not in the timelines.
Bugs
“Recovered clips” bin and duplicate clips — The annoying “Recovered clips” bin that used to appear after sharing sequences returned in a new form. Periodically I would find this bin in my edit project with one or two duplicate clips. It took me almost the whole edit before I figured out the trend. This happened every time I used “Replace With Clip…> From Source Monitor” (available when right clicking a clip in the timeline). I use this function so often I added a keyboard shortcut to make it really easy. Once I figured this I had to either stop using the replace function or accept that there would a bunch of duplicate clips cluttering my edit projects.
- And, along the same lines, the other replace option: “Replace with clip…> from bin” doesn’t seem to work at all between projects. (I don’t use that option nearly as often, so I can’t say I thoroughly field tested it.)
Occasional Media Linking issues — Occasionally, I decided to relink certain archival clips from a lo-quality mp4 source file to a Pro Res Transcode in the middle of the project. In at least one case this led to a minor media linking issue. I had been getting an artifact whenever I rendered a particular archival clip so I made a Pro Res transcode, relinked to the transcode within premiere and left the original file untouched. This solved the render artifact. Later, when my Edit project was open, but the Source project for the archival clip was closed, the clip in the sequence reverted its link to the original mp4 source and the render artifact returned. When I opened the Source project, the link between the clip in the timeline and the Pro Res transcode was automatically restored. However, this happened over and over with the same clip. Of course, it’s best to avoid this sort of media re-linking mid project, but sometimes it’s unavoidable. (Feature request)
Risks?
From the chatter I hear in my relatively small network of doc editors Productions has already become a standard workflow for feature docs. None-the-less, it is a major change to the way Premiere functions and thus should be approached with well-informed caution. Within a Production, Premiere has to keep track of media, markers, nests, timelines — ie everything — across many projects. This requires a whole new back-end infrastructure to manage changes and various inter-dependencies across these many projects. This opens up many possibilities for things to get messy.
For example, in 2022 I was asked to support a project that was experiencing massive issues after moving into Productions. After a lot of troubleshooting and eventually getting Adobe engineers involved we determined the issue was related to “legacy” clip markers that had originated in a much earlier version of Premiere. Though you wouldn’t know it on the user side, Adobe, at some point, changed the way markers work within the software and didn’t account for the way older markers would behave once migrated into Productions. This has supposedly been solved in recent updates, but the fix was too-little-too-late for the project I was supporting.
While this specific problem might seem rare, in the indie doc world projects sometimes span many years or require digging into old archived projects to find crucial archival material. I wouldn’t be surprised if there are still unknown bugs in how these sorts of “legacy” projects might behave once updated and moved into Productions. If your project spans many years and many versions of Premiere, I would suggest avoiding Productions or taking some time to thoroughly test Productions to see if you notice any strange behavior. If you are on a new project but need to pull up archived footage from past projects, I would suggest leaving behind old project metadata and starting fresh with new transcodes from the RAW camera originals. Be especially wary of any baked in clip markers or metadata from older cameras or formats.
Troubleshooting in Productions
A few months into the edit I experienced a major show-stopping technical problem. Every save started taking longer and longer until a single save lasted 20 min or more (if I didn’t give up and Force Quit first). My first reaction was to blame Productions. I had a decade of experience troubleshooting within Premiere, but it felt like I was in new terrain with Productions. Some of the old troubleshooting steps looked different in a Production.
It turned out the issue had nothing to do with Productions and Productions actually gave me troubleshooting options I didn’t have before. The film was about an author and I was using mp3 rips of her audio books as temp VO. I eventually discovered that any project referencing one particular audio book was experiencing these absurdly long saves. Once I discovered the source of the problem, I moved all the audio book clips and assemblies into their own projects. Then I made new wav exports for each audio book excerpt I was using and cut those excerpts into a copy of my latest edit sequence in place of the full length audio book clips. Once there were no more references to the full audio book clips in the latest edit I moved a copy of that sequence into a new edit project. Then I labeled each project that referenced the old audio book files “OPEN WITH CAUTION”. What was great about using Productions in this case is that I could still open up any of the OPEN WITH CAUTION projects, and copy and paste or export from these problematic sequences. As long as I closed the problematic projects without saving there was no issue. I could continue working and saving in all other projects like normal.
A Word With Adobe
I had the pleasure of talking with several Adobe engineers about my experience in Productions and I was very reassured to hear that most the caveats I experienced were already on their to do list. In fact there would have been a few more issues in this document had they not already been fixed in recent updates. I don’t expect all the issues I mention above to go away soon if ever, but I am confident that Productions will keep getting better.
Onward
I hope these notes have been reassuring for anyone considering Productions. Looking back on the experience it really is incredible how few issues I came across considering how dramatic the change to Productions is. It certainly took a little time to adjust to the new set up, but any anxieties I had during the transition quickly dissolved. Nothing about Productions inhibited the creative process. Instead I found Productions to be incredibly stable and flexible. I will definitely use it again for all future feature edits.
Tech Specs:
Premiere 2020 Version 14.3.1
Computer:
iMac(Late 2015)
4GHz Quad-Core Intel Core 17
64 GB ram
AMD Radeon R9 M395X 4GB
Storage:
G-Tech GRAID 2-Bay
Thunderbolt 3
20TB(2x10TB)
Playback:
Blackmagic UltraStudio Express
