I know the work arounds, and agree with OP.
Adding new staff configurations to the global library of ‘instrument choices’ will be a welcome addition.
In the meanwhile, perhaps posting a list of stave builds/instruments you’d like added to the list would be something the dev team could add for the next release. Particularly if there is a suitable associated sound for it already somewhere in the HALion content libraries that come with Dorico.
That sort of request doesn’t involve a ton of coding and testing. It can just be ‘added’ to the existing library.
I suppose they could also add a slate of ‘generic staves’, that don’t have an instrument end point set up out of the gate at all? Maybe just have ‘numbers’ for the instrument names…this way a user could set them aside and call up instrument templates for it without taking up slots for already named instruments.
I sense the ability to do our own is already on the road map for the dev team and coming eventually. We must be patient. Some of the things we request might already be possible if you have the developer tools to cli in the commands. It just takes time for them to get it all right, build a good UI for it, figure out the best place for it in the main GUI/work flow, do user studies and get feedback on UI choices, and make sure it doesn’t break anything else…plus chart out implementations that hopefully avoid some sort of major bottle neck in future development.
In theory, adding a new instrument to the list might be as simple as adding some stuff to an XML file in the right places. In practice, the team has to be extra careful before putting things in a release. It can also open a whole new can of worms, as users quickly demand immediate control to the end point instruments, and when it comes to third party plugins, the info required to get a plugin to open and load stuff can be ‘proprietary’ and not available to end users like us. I.E. If you open the XML that holds that information, there’s a bunch of stuff that gets handed off to HALion to set that plugin up. At this time, there is no obvious way for users (advanced even, let alone the not synth savy user who runs into form entries that can hold these sorts of commands) to get the information to communicate with HALion like this.
All that can also lead to the potential difficulties of linking stuff up with the user instrument templates, which can store a whole plugin state by regular standards, but can’t always talk directly to a plugin like it can with HALion.
I think there may well be a way to store custom staves in Dorico at the global level in some way similar to OP’s request ‘already’ at engine level that that it’s not time to share with end users yet.
When it is ‘ready’…I think it’s something a significant number of Dorico users would quickly take advantage of, and often. I also would be willing to bet the Dorico team has it on the drawing board…just have no idea how many other intermediary steps must be sorted and tested first. My guess is they’re ‘on it’…it’ll simply take some time before it’s safe and effective to give us users a UI to start poking in our own stuff.
It’s a very common sense request really, and something I have little doubt that the dev team wants as badly as we do. In this case, I feel like we’ll get it when it’s ready.
Meanwhile, we use the work-around methods.