Part of the question about this may lie in assumptions or expectations.
It took some time of working within a Productions workflow for me to fully realize how massively different this process is. It isn't just a 'take the organization from a project and put some in folders and link the projects' bit of sleight-of-hand, based on the old stand-alone project files. If it were, then I suppose "shrinking" a production back into a project file would seem like a natural reversal.
Productions and stand-alone processes and workflows are different from the very core of each process.
You do have to accept that statement, and completely abandon the concepts used in stand-alone project workflows while working in Productions. And to get "there", I suggest thinking about this from the concept of The Job, not The Project.
Define The Job ... whether it is a single specific job for a specific client, all jobs for a specific client for a year perhaps, or all jobs for a small shop for a year. Create your Productions organization to best work within the Job as you have defined it.
And none of the above paragraph was ever possible with an old-style stand-alone project file/process.
Stand-alone projects are based on the metadata within the project file.
Within the old-style stand-alone process, the entire organization of the Job you are working on is based on two things: the organization you created in setting up bins for assets within the project, and the metadata that Premiere gathers from your bin organization and from ingesting those assets. None of that information is available outside that project file.
This is why when you have two project files open and drag/drop something from one project file into another, Premiere completely duplicates all of the copied assets and all metadata for them from the one project file into the other.
Production Jobs are built on the on-disc organization of the folders within the top level Production folder, combined with the linked metadata of all project files included in that top-level production folder.
In a Productions process, Premiere is not dependent on the metadata within each project file of that process to encompass all metadata for that entire process ... that Job. The metatdata is spread around through all the linked folders and project files of that productions process.
Remember, we are actually now working with project files that are the equivalent of a single bin in a stand-alone project file process. So even a medium sized Job can have 50 project files between those used as simple bins and those actually housing sequences. Where you had a top-level bin for Media with maybe 10 sub-bins, now you have an on-disc folder for Media project files ... and that folder includes ten project files, each holding only what each sub-bin had held before.
This enables the program to run with far less metadata loaded to memory/cache at any one moment. And at the same time, allows for a far deeper and broader organization of an editor's work within Premiere.
But there is no natural route for migrating all that diverse and diffused data down into one old-style project file. How would it have any idea which project files should become bins? Which project file should be the job project file? There are so many ways each user can organize their work, and can organize different parts of a job differently.
And as the entire approach to working within Premiere is changed, so is the archiving process.
Yet in some ways, it's the same. You archived a Job before, when each Job was it's own project file. Now you archive the Job as a Productions folder-set. You're still archiving The Job. But that Job is structured differently.
Neil
14
Replies
AdChoices