A faster way to rename staves and making them visible


Renaming staves is now done by going to the Setup page, opening a Player, opening the Instrument Edit Name dialog, editing the long and short versions of the name.

Then, you have to make them appear in each flow and layout where you want them to appear.

Maybe a grid, with the available staves on the left, the long and short names in the following columns, and the flow and layout names in the subsequent columns could make this process faster?

I mean, something like the example I attached to this message.


The beauty about the current system is that you can multi-select a bunch of players in one go and assign them simultaneously to flows or layouts; or you can multi-select a bunch of flows and assign them to a bunch of players or layouts; or you can multi-select a bunch of flows and assign them simultaneously to players or layouts.

Though I understand what you’re asking for in regard to instrument names, I’m struggling to understand how you’d maintain three dimensional relationships from within a two dimensional table.

Pianoleo, the example I posted is not clear enough (I’ve unfortunately deleted the original sheet, so I can’t quickly rebuild it now).

However, my idea is that the table/grid is actually divided in various sections. As you may see by the thicker vertical line, each Flow starts a new section. Inside each Flow section you can assign staves to the layers inside that Flow/section.

This representation shouldn’t replace the existing one, but offer a more comprehensive overview. It is a bit like the inputs/channels/outputs matrix in a surround patcher.


I’m thinking that the grid I’m thinking to could be an extension of the current Endpoint Setup grid. An overview on the matrix starting from instruments, being assigned to flows and layouts, ending into sounds. All manageable from a single window.


I started writing up a detailed explanation of why I don’t think such a table makes sense, but deadlines got in the way, so I’ll summarise:

  1. Various things appear to be impossible from such a table, but are actually possible. Various other things appear to be possible from such a table but are actually impossible. As a result many of the tick boxes on your example are redundant.
  2. It’s not easily scalable: once you’ve got lots of players or lots of flows it becomes unwieldy.
    Then there’s the question of when the actual processing takes place: it’s not very “Dorico” to hit an Apply button after performing lots of changes, and it’s complicated by some options being dependent on what else is already ticked (or unticked).

Of course, it doesn’t really matter what I think :slight_smile: