sticky default file-names

hi there,

First of all, much gratitude for Dorico 3! It’s nice to be able to scroll left and right using the arrow keys.

Secondly, in the print menu — I’m fond of Dorico remembering my settings for printing vs. PDF and the directory – these things it remembers on a per-project level, which is very helpful. (I still get nightmares from Tantacrul’s Sibelius rip… “Remember my settings… Remember my settings…”)

Less helpful is the “Filename Options” window, which remembers its settings globally and not per-project. This is less helpful – especially when working on multiple different projects in the same day, such. One project may very well benefit from a formula like $n-peter-$t-$l but this less helpful when you’re working on a piece for solo piano (which wouldn’t need a layout name in the file), or when you’re working with a song with an exceptionally long name (00-Nikolay_Rimsky-Korsakoff-Supercalifragalisticexpiialidocious-Clarinet_in_B-Flat1.pdf).

So it possible in the future to have the “Filename Options” be remembered on a per-project level rather than globally?

thank you!

This has been suggested before. I decided to implement the Filename Options settings as application preferences, but perhaps we will revisit this decision in future.

Maybe people can choose their preference? I find myself endlessly replacing the “filename options” window because I can’t find a way to make “filename ingredients” fit all of my projects needs uniformly. Some projects need version numbers, some don’t. Some need layout names, some don’t. Some have impossibly titles or composers and need adjusting, some don’t. Some projects have titles in a different language, which I typically anglicise for file name purposes. When working with multiple projects in the same day (which is often, as requests come in throughout the day for changes and revisions), it would be nice for Dorico to remember my file-naming structure for that project and not mess with others.

Thank you for considering!

PS it’s particularly helpful to keep file-name structure consistent per-project because a lot of what happens today is uploading PDFs of scores and parts to Dropbox, and sending the link to the performer(s).

A simple solution would be to set up your filename recipe for the current project, then copy and paste it into a Comment (attached to bar 1?). Then do the same for each of your other projects. When it comes to exporting, you just need to copy and paste the contents of the Comment.

i suppose that could work as a temporary fix.

I’m curious, what’s the argument for keeping “filename options” as a global preference?

Because many users find that they don’t need different filenames for every project, and re-setting them for every project would be tiresome.

Edit: Daniel beat me to it.

I can see your use case, but I have a filename format I set once and forget. I’d hate to have to re-create it every time I create a new project!

Dan Kreider – I’d be curious to see what your file name format is. Because “recreate every time” is what I end up doing all day.
If you had to “recreate every time” on a new project, you could simply put the filename options in your template for new files.

One issue that could come up (and has come up for me often) is if you export only certain flows of a piece.

For instance, you’re exporting Mozart Requiem, and your file name format is $n-mozart-$t-$l.pdf
then you want to export a piece by beethoven the same day

so you have to change it to $n-beethoven-$t-$l.pdf
then you want to export only the first movement of the mozart
so you change it to $n-mozart-$t-kyrie-$l.pdf

and so on – if you’re working with two different projects every day, this is tedious! Especially since the programme already remembers that you. want to export mozart to \mozart and beethoveen to \beethoven

hypothetical examples, obviously…

Mine is


It works for me. If I want to save other versions, I group them in folders.

that would never work for me, sadly. I tend to put version numbers (or at least date) into the file name, because if I deliver a folder that’s called “v2” but the file names are still the same, that could confuse people into thinking they already had the latest version.

And I tend to put the composer name into the files, too, so it’s easier to search…

but again — all of this needs to be adjusted on a project-by-project basis…

For this, I save the file as a new filename: “My Project_Proof 17” or whatever. So the proof number is in the PDF. I tend to keep all the Dorico files, but only save the most recent PDFs.

Since there’s always a lot of back-and-forth with clients, I’ve found the “Proof X” system works really well to remove ambiguity.

that could work. I haven’t really explored using the file-name ingredient too well. thank you!

a related question - is there a reason why “composer” and “arranger” are left off from the filename ingredients list?

Where do you draw the line? If you add composer and arranger, work number is also a candidate. Copyist, publisher, and editor could be useful as well. Also artist, if you are making different arrangements of the same piece for different performers…

But you might expect the project name and/or the directory structure the projects are organised in would contain that type of information, if it is relevant.

Regarding saving filename recipes globally or locally: Wouldn’t the obvious solution be “set globally, override locally if necessary”?

(If only I remembered where I’ve seen this mechanism before.)

even more arguments for keeping the “filename options” project-based than globally-based…

I’m reminded of the Scott Adams (Dilbert cartoonist) joke: “I don’t do irony, I send my shirts to the laundry”.

Oh well, not to worry…

I love how, in a programme that’s otherwise highly customisable, this is the one thing that seems to be one-size-fits-all.

An possible solution for is cloud be. Keeping it globally, but with option to save a list of ingredients list and choose it from a drop menu, with the ability to add/remove. To keep it simple, the last option used would be saved for the next time.