FR: Tokens tied to layouts

I’ve read around the forum, and this has been suggested before, but my use case is rather different.

I often write vocal lead sheets for my students and adding a layout with a transposition override is a brilliant way of creating a version in a different key.
Some of my older students prefer to have the lyric text enlarged, creating even more variations on the original layout. Having these layouts in the same file and attached to the same player makes updates really simple.

However, new layouts are often created long after the original project.
In order to keep track of all the versions, each of my scores has a footer like this:

The center consists of the project title and text. Layout tokens would be an easy way to add the version and date information on the left and right.

I have just tried the workaround, suggested in another thread, of creating a new master page (page template). It works, but it’s fiddly, and including explicit information in the page template rather goes against the Dorico philosophy.

Having some generic layout tokens that could be edited as desired would make it much easier to utilise the power of Dorico’s Player / Flow / Layout organisation.

Thanks for your suggestion. I’m not 100% clear what specific tokens you want to add. Do you mean that you would like to have some tokens defined in a kind of “layout info” dialog or similar, so that you can have tokens whose values vary by layout rather than by flow?

Yes, I’d like tokens that vary by layout rather than by flow.

I suggested “generic” layout tokens (eg {@layout1@} {@layout2@} etc) only because I imagine that each of us will use the tokens in different ways, but having the same fields that exist for project and flow tokens would be fine.
Many of us are repurposing those fields to contain other information, and of course it’s a nice Dorico feature that we can include tokens within those fields.

If you add Layout based tokens, I’d love to see some sort of way to automate labelling for layouts with players who double. For example, a “Reed 1” part may have this on the first page, with the player name and all instruments required …


… and then have this on page 2, showing the player and the instrument they are playing at the beginning of the page.

That last part I think you’ve said before is tricky, but it would be a cool feature anyway.

1 Like

You can almost get the first page one. The staffLabelsFull token gives a one line comma separated list. A vertical instrument list token would solve that.