I know that very well. You’ve made many valuable contributions here.
My worry was that this sort of thread might lead novices to conclude they had to do something complex, where there might be a simpler solution.
Well, that’s a very possible, but unfortunately in my case this is the only solution.
Currently Dorico doesn’t have a Custom Instrument Creator/Editor, so workarounds are needed in order to create dedicated instrument ID in order to fix the problem.
Now I’m facing another one… Dorico doesn’t want to read the additional entries… 
Best wishes,
Thurisaz 
Hmm … I’m not sure why they wouldn’t work as they work on my system. Obviously you made backups of the original XML files, and then overwrote the current files with mine? You’ll need to close and then re-open Dorico, but if you’ve done that I’m not sure why it wouldn’t work. If you go under Sketch, do my 0-line and 1-line instruments show up?
Hi @FredGUnn,
Yes I made backups of the original files, then I pasted yours in the folder and started Dorico.
The native Dorico instruments are visible, but the entries created by you are blank slots.
Fred, would you, please, try to open these files of mine on your computer?
Qanun Thurisaz.zip (103.1 KB)
Are you able to see the Qanun under Strings?
Thank you very much for your time!
Best wishes,
Thurisaz
Yep, it shows up for me! I see it’s a grand staff instrument too.
1 Like
Thank you very much, Fred!
I don’t have an idea what makes the custom entries unreadable from Dorico on my computer?!
I hope someone from the team could give me an idea how to solve this issue!
Best wishes,
Thurisaz
@FredGUnn,
Finally I was able to resolve the problem…
I was keeping the backups under names orig_instruments.xml, orig_instrumentFamiliesDefinitions.xml and orig_instrumentnames_en.xml inside their original locations. Somehow this led to conflict with the edited ones.
Why Dorico is scanning files that have different naming scheme?!
Best wishes,
Thurisaz
Congrats, this is really wonderful! — great fun to listen to and, I expect, even more fun for those students lucky enough to play in it!
That’s definitely odd. My own naming scheme is to keep a backup of the factory settings and a copy of my version. Whenever the files are overwritten with an update, it’s easy to just delete the file, copy and paste my backup, then rename it. Dorico doesn’t seem to have an issue with all of these coexisting in the same folder anyway.
Thanks!!! Definitely the most unique group of instruments I’ve ever had to write for.
1 Like
Hi @FredGUnn,
With the naming scheme of yours everything is alright, even if I’m saving the factory file at their original folders.
I suppose prefixes with small letters don’t prevent Dorico of identifying the files?!
Thank you very much for the assistance, Fred!
Best wishes,
Thurisaz
1 Like
Based on the information in this consequential post, I moved away from messing with the default Dorico files (instruments, instrumentnames, families and score orders).
Instead, creating “Default Library Additions” folder (if it doesn’t exist yet) and then creating the small xml library files only for the custom instruments or the custom score orders or the custom paragraph and font styles is a much neater and safer solution:
Modifying factory-made files is
(a) more cumbersome,
(b) will be overwritten with updates and
(c) the information for each instrument is kept in several files that are cross-linked to each other (instruments, instrumentnames, families definition and score orders).
However, a Doricolib file is an XML file that keeps all that information in a single place instead of 4 different files. Below is a screenshot with a tree view:
From what I have tried so far, Dorico will load all files sitting in this folder once factory-made libraries finished loading. This makes it possible to create very small libraries that only contain the required nodes (eg the three I’ve circled) and remove the duplicate unchanged nodes to streamline everything and further reduce the chance of error:
Finally, regarding the customized routing of instruments - in my experience taking a standard factory instrument, renaming it and preserving the unique routing will not work when such an instrument has a defined parent. In such cases, I usually found that Dorico would insist on routing it to the parent when the template is reapplied.
This is I suspect the reason violins can be renamed and the custom routing will be preserved, while a Sketch Grand or Treble Staff will go back to whatever the piano is.
There are multiple instruments in Dorico that have a parent (bass tubas, the A clarinets, trombones, etc) and for the most part it is quite logical and makes perfect sense. Until the instrument editor arrives in the future, manually customizing instruments might be needed in some cases and hopefully errors can be minimized with precautions like those described above.
2 Likes
Hi @ebrooks,
Very interesting approach! Would you, please, show me how it looks in Dorico?
How the things are organized inside the program itself?
Some screenshots will be very welcomed.
Thank you very much!
Best wishes,
Thurisaz
Hi @ebrooks,
Pretty nice! Thank you very much!
I would like to ask you something…
Is it possible to have a multilingual .doricolib file?
For example this code:
<instrumentNames>
<entities array="true">
<InstrumentNameEntityDefinition>
<entityID>instrumentname.strings.qanun</entityID>
<name>Qanun</name>
<parentEntityID/>
<inheritanceMask>0</inheritanceMask>
<data>
<uiName>Qanun</uiName>
<singularFullName>Qanun</singularFullName>
<singularShortName>Qan.</singularShortName>
<pluralFullName>Qanuns</pluralFullName>
<pluralShortName>Qan.</pluralShortName>
<gender>kNeutral</gender>
<language>kEnglish</language>
</data>
</InstrumentNameEntityDefinition>
<InstrumentNameEntityDefinition>
<entityID>instrumentname.strings.qanun</entityID>
<name>Kanun</name>
<parentEntityID/>
<inheritanceMask>0</inheritanceMask>
<data>
<uiName>Kanun</uiName>
<singularFullName>Kanun</singularFullName>
<singularShortName>Kan.</singularShortName>
<pluralFullName>Kanunen</pluralFullName>
<pluralShortName>Kan.</pluralShortName>
<gender>kNeutral</gender>
<language>kGerman</language>
</data>
</InstrumentNameEntityDefinition>
Thank you very much once again!
Best wishes,
Thurisaz
I have no idea! If you look at the node structure of any “instrumentnames_X” file, each language gets its own tree of the instrument names. However, they are all nested under the same Score Library.
English:
And Spanish:
Based solely on this, I wonder if this is a possibility that might be worth testing. For example, creating the second “instrumentNames” node in the doricolib file for the custom instrument so that instrumentNames are given in two languages in a single custom library.
Perhaps Daniel might have a minute to confirm if this is the case or not. So far, my experience has been that as long as there are no duplicates, Dorico behaves as if all these files in their various locations are one big library.
Love it because it gives a nested tree view and because I can copy/paste the entire nodes (with everything inside) between files. Good luck - if you learn something, please share for the others’ benefit.
1 Like
Hi @ebrooks,
I’ve done this, but unfortunately it doesn’t work…
Having multiple separate .doricolib files for the supported languages doesn’t helped too…
Currently I’m able to create a custom instrument.doricolib file in only single language.
Most probably @dspreadbury, or someone else from the team, could help here?!
Best wishes,
Thurisaz
What worked for me is making sure that the doricolib file has the full set of entries for instruments, instrument names, families definitions and score orders. And what I was suggesting earlier to is experiment with adding another node for instrument names in a different language to that file, that already works in English. I don’t know if this makes a difference, but the way your screenshot looks is that all those other components are missing and only the instrument names are shown here. If you want to, post the file and I’ll test it tomorrow?