How to change the scratch disk location by default

[SrK]

Hi,

I work in an small studio (we have like 5-8 users) we save or work in a network server than them is sync it with dropbox.

What im trying to do is to get the "Scratch files" to always stay on the local computer, for all new projects.

And not to go each time and change the option manually. Is this possible? thanks

[R Neil Haugen]

If you're talking about the cache files, it is not recommended to put those on a network server, as they are accessed continually and heavily and should be on a local internal drive. High-speed at that.

As to the other files ... all settings of the Scratch Disk stuff are typically 'sticky', so once a user sets them with the options available, they will default to that.

So say for auto-saves, if you select the "with project" option, it will always on a new project assume the auto-saves will be in the same upper folder of the project file location.

Neil

[Warren Heaton]

Create a new Premiere Pro project with the desired General, Scratch Disk, and Ingest Settings then save it as "Template Project.prproj".  This can also contain Bins with the preferred structure for organizing source footage in a project as well as a pre-made starter Sequence.

Then, make a duplicate of the Template Project file and rename it as needed when starting a new project.

[Averdahl]

And not to go each time and change the option manually. Is this possible? thanks

By @SrK

As Neil pointed out Media Cache Files and Media Cache Database should be on an internal drive. 

For scratch files, go to File > Project Settings > Scratch Disks and do the settings there, for let´s say Video Previes, Audio Previews, etc. By doing this they will stay on the local computer. The files that already are on the "wrong" disk will not automatically be deleted and/or moved to the new location, so doing some manual cleanup may be necessary.

The Scratch Disks settings are sticky, so all new projects will use those settings.

[Remote Index]

The problem, here, of course, is that settings like "scratch disk" should be primarily associated with a workstation, not with a project. It's a design choice that doesn't reflect the way users work. (There are cases where you would wish a project's settings to over-ride the default workstation settings, which should be an option in dialog.)

R.

[R Neil Haugen]

I don't see the problem, actually. Because the Scratch disk options include multiple things, some of which are specific to that computer and some of which are specific to the ... organizational? ... needs of the workplace. So it's got both things inside.

Plus, the current Scratch Disk options are set & forget. The user sets them during the first project from several option, then probably never touches them again.

Local Items

For cache files, all "workstations" should have their cache files local. Decide whether having previews should be 'local' or 'network' for your system. I've seen both used depending on network delivery speeds & organizational decisions.

System Items

Other things are more of a system setting. Or to fit an organizational need. Like where the project file is stored, and all of those are selected from a list. So they can be set to the organization's preference for such things on their network.

And again, for all future projects, those settings will be applied. Period.

They are then the defaults. Set once.

Neil

[Remote Index]

(NOTE: As it’s been two weeks I’ll respond here to what was arguably a derail I started - in the belief that there is no longer a core concern to “derail”, and that the issue we're discussing - while fairly abstract - is still relevant to questions of the design of the software.)

R Neil Haugen,

Thanks for the thought and response. But I think your response actually argues the very point I was making.

Specifically, you talk about the Scratch disk location as settings, “some of which are specific to that computer and some of which are specific to ... the workplace.”. You give the following examples (emphasis mine):
- all "workstations" should have their cache files local. ... previews should be 'local' or 'network' for your system.
- Other things are more of a system setting. … So they can be set to the organization's preference

I note that none of your examples outline a project by project need (ie. project settings) but only workstation, system, and organization needs. My argument is precisely this - these settings do not address variables that change from project to project, settings that thus should be associated and travel with that project - but system needs which are local and should not be associated with or travel with the project.

Note here, that there will be exceptions - that there will be some cases where a user desires such settings to be associated with and transported with the project; these are precisely that - exceptions which prove the rule.

Your contention that “The user sets them during the first project from several option, then probably never touches them again.” does not allow the for the constant need to address these settings on projects which are passed from user to user (across computers, organizations, settings) - a not-uncommon occurrence. Such sharing demands that these setting do indeed need to be checked and adjusted - on a project by project basis - despite them addressing concerns which are almost always workplace / workstation / computer based (not project based) as you have helpfully pointed out.

R.

[R Neil Haugen]

Very nice response, with good thoughtful comments about different workflows.

First, I always default to giving the user more default choices. So I'm happy to support that all the way.

Second, the devs are pretty clear that for instance the cache files should always be set to local storage. Anyone is welcome to try other networked locations, but well ... doing so is most often problematic.

And due to the need for constant high-speed access to those files, if the cache and the media files are both accessed via the network cable, well ... it better be a totally awesome speed system.

So that part of the settings ... just needs to be local for general best operating practice.

As to the others ... well, they are sticky, so if set one way, create a new project, they will 'start' the same. But you can change them of course at need.

If you create a project with certain scratch disk settings, and the project file is then opened on another machine, that project should still have the original scratch disc settings with it. So if used on a network, for example, the locations should be the same.

Is that not working in your shop?

Neil

[Warren Heaton]

@Remote Index 

I've made heavy use of the "Same As Project..." for Scratch Disk settings for freelance remote editing over the past decade and a half or so - ever since 1080 ProRes (and now 2160p ProRes) plays smoothly from USB3 and USB-C storage media.  It's mostly small editing teams in different locations for shorter format projects like product videos, industrial videos, music videos, and short documentaries.  With this approach, we know that everything needed is within the same folder for the project.

For those whose work is like that, I'd not like to see "Same As Project..." get overridden by an application-side setting.

The one setting I've avoided using "Same As Project..." is the Auto-Save location.

[Remote Index]

Warrent Heaton, R. Neil Hagen,

An ongoing issue I have had is if a project or production is opened without the necessary volume mounted (ie. the location of the auto-saves etc. is not present) then the location of these caches is reset, and the reset location persists. This occurs without notice and without a dialog, and so it is very easy to forget this, even if a project or production is opened by accident.

Anyone who has ever gone on a hunt for auto-saves knows this annoyance.

The whole theoretical question aside (which is how I started this side-thought), a simple dialog with "cancel" option would go a long way to addressing this problem.

R.