Save relative export path and naming pattern with project?

Dorico
1

Hi Dorico community,
I mostly enjoy using Dorico, but one thing I really find annoying in my everyday use is (PDF-)exporting different projects on different machines (folders synced via cloud). I’m a teacher, so I use a lot of different project files and come back to them later, make a few changes (e.g. change a song to another key) and export again. I’d really like to:

  1. Save file naming options with the project. So I can have e.g. one Project “$f - $n $l” and another “$t ($d) - $l” and don’t have to check this every time I open the other project again. It doesn’t make much sense to me to change this while working on the same project, but it does to use different patterns depending on the project.
  2. Save Target folder paths relatively to the project file instead of absolute paths. I often open the same project on different machines and always have to adjust the paths just to get the same result (I’m mostly saving my PDFs directly besides the project or in a subfolder to keep a project together - not caring about parent structure).

I change both of these in print mode of the project window so I’d expect these to be stored in the project, but this doesn’t seem to be the case with the naming pattern: If I open the same project on a different machine, I always get the values I used last time in Dorico on that machine instead of the values I used with that project. The Target folder paths actually do seem to load from the project file, but as absolute file paths. This is completely counterproductive if I use the same file on different systems or platforms (Mac and PC).

BTW I found another thread regarding Point 1: Why do file names transfer to different files? If I read this correctly, my problems are intended behaviour to maintain company-wide naming and the pattern should change as seldomly as possible. Well, that may be useful for a few of us (those using Dorico for one employer only with always similar kinds of projects). It shouldn’t be difficult though to add a global system setting like “Ignore project export settings on this system and always use these: …” for those people who like it the way it is now. So for me, @Steinberg please consider this post a feature request!

What do other users around here think? Do you enjoy it the way it is or maybe have any workarounds?

PS: There seems to be a slight mistake in the documentation of the file name options dialogue: The button “copy to all” does not care about the project’s layout but the different file formats (as I mentioned it’s a systemwide option and independent from the project).

2 Likes
2

Indeed it seems that the export pattern is a global preference, not a document property.

This bites me painfully every day — teacher here too! —

Sibelius stores this in the document, even though it often forgets to save your edits between sessions. It would be great if Dorico would change this so that each project had its own exporting path.

Then, of course, a global pattern could be set in Preferences so that new documents would use that one. Ah, and another thing: if you change the pattern of the file name for exported Slices it propagates to the export pattern for the PDFs too! Discovered this the painful way again quite recently.

4 Likes
3

Chiming in to say that I hate this “feature” with the passion of a million burning suns. My directories are littered with mis-named files because we can’t have a simple file naming interface like every other program on the market. The Developers have made a choice to prioritize one specific use case over creating a more universally accessible file saving dialog — in which it is likely entirely possible to use tokens if this is a high priority for some. But the current setup inevitably fails users who use other common programs like, you know, word and Indesign, and etc. because the file path must be defined for each layout (and persists), but the file name is somehow universal and comes from whatever last file you opened, not the file you are working with. This is a UI/UX nightmare.

2 Likes